Ulrich Drepper wrote:
> Neil Brown wrote:
>> Does it also specify how to find out what granularity is used by the
>> filesystem? I had a need for this just recently and couldn't see any
>> way to extract it.
>
> That's still on the table. We might end up with an fpathconf() solution.
OK, the pathconf()-based solution will most probably be in the next
POSIX spec.
Now, somebody has to provide a way to get to this information. The
kernel does not export it so far. Is it finally time to break down and
allow pathconf() and fpathconf() syscalls into the kernel?
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
On Thu, May 10, 2007 at 11:26:36AM -0700, Ulrich Drepper wrote:
> >That's still on the table. We might end up with an fpathconf() solution.
>
> OK, the pathconf()-based solution will most probably be in the next
> POSIX spec.
>
> Now, somebody has to provide a way to get to this information. The
> kernel does not export it so far. Is it finally time to break down and
> allow pathconf() and fpathconf() syscalls into the kernel?
I'd be happy to have them. While it's not the nicest API in the world
it's in Posix and we have to support it at the library level, so we
should better get it right.
I'd like to avoid having a big swithc statement in every filesystem,
though, instead of we should have a table-driven approach instead
where each filesystem defines one table (or multiple ones when it
supports subtypes with different limits) and just sets a pointer in
the superblock to it.
E.g.
long foofs_pathconf {
[_PC_LINK_MAX] = 16384,
[_PC_2_SYMLINKS] = 1,
...
}
and then in fill_super:
sb->s_pathconf = &foofs_pathconf;
Christoph Hellwig wrote:
> E.g.
>
> long foofs_pathconf {
> [_PC_LINK_MAX] = 16384,
> [_PC_2_SYMLINKS] = 1,
In general I agree. But what do you do for network filesystems? Maybe
we'll have a network filesystem protocol which allows to query the
remote server about the underlying filesystem. Then the return value is
dynamic and it's the maximum (coarsest granularity) of the network
filesystem itself and the underlying filesystem.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
Christoph Hellwig wrote:
>
> I'd be happy to have them. While it's not the nicest API in the world
> it's in Posix and we have to support it at the library level, so we
> should better get it right.
>
> I'd like to avoid having a big swithc statement in every filesystem,
> though, instead of we should have a table-driven approach instead
> where each filesystem defines one table (or multiple ones when it
> supports subtypes with different limits) and just sets a pointer in
> the superblock to it.
>
This is starting to sound an awful lot like statfs(). Maybe we could
create a new statfs call which takes a buffer size input (so that we can
add new fields as time goes on) and which returns the necessary information?
-hpa
On Thu, May 10, 2007 at 12:44:19PM -0700, Ulrich Drepper wrote:
> Christoph Hellwig wrote:
> >E.g.
> >
> >long foofs_pathconf {
> > [_PC_LINK_MAX] = 16384,
> > [_PC_2_SYMLINKS] = 1,
>
> In general I agree. But what do you do for network filesystems? Maybe
> we'll have a network filesystem protocol which allows to query the
> remote server about the underlying filesystem. Then the return value is
> dynamic and it's the maximum (coarsest granularity) of the network
> filesystem itself and the underlying filesystem.
You're right, we'll probably want a method call for it. The table
approach might still be a nice helper for the normal case.