LKML Archive on
help / color / mirror / Atom feed
From: Neil Brown <>
To: Ulrich Drepper <>
Cc: Christoph Hellwig <>,,
Subject: Re: [PATCH] utimensat implementation
Date: Fri, 11 May 2007 12:14:45 +1000	[thread overview]
Message-ID: <17987.53653.111396.778502@notabene.brown> (raw)
In-Reply-To: message from Ulrich Drepper on Thursday May 10

On Thursday May 10, wrote:
> 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?

Maybe... certainly we want some way to get at this information.

It has occurred to me a number of times that there is no easy way to
export information about filesystems from the kernel.

One specific example is request statistics for an NFS filesystem.  We
can get system-wide statistics, but to get stats for a single
filesystem isn't possible, and a big reason for this is that there is
no-where to put that information.

Filesystems also have a variety of mount options and they are only
available through "/proc/mounts" and can only be change by "remount"
which is a bit of a clunky interface.

Just about every other kernel object is, or can be, exposed through
sysfs.  But filesystems cannot.  This is presumably because there is
no unique handle for them (what with name spaces and bind mounts and
so forth).
Each filesystem still have a unique device number (->s_dev) so that
could be used. e.g. we could create

which would contain info about the filesystem with device number 0:3.
We could then put time-granularity and other fs-specific info in

I feel that would be more flexible than a specific fpathconfat system
call.  But would it be enough?
The pathconf values can apparently be different for different files in
a filesystem.  Is that important?  If it is, we really would want
some new syscall rather than just sysfs attributes.

So that makes two questions for anyone with opinions:
 1/ Does pathconf have to be per-file, or is per-filesystem OK
 2/ Can we have a way to put attributes for filesystems in sysfs?


      parent reply	other threads:[~2007-05-11  2:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-26 22:49 Ulrich Drepper
2007-04-26 23:25 ` Andrew Morton
2007-04-27  0:11   ` H. Peter Anvin
2007-04-27  0:55     ` Ulrich Drepper
2007-04-27  0:58       ` H. Peter Anvin
2007-04-27  1:04         ` Ulrich Drepper
2007-04-27 23:15           ` H. Peter Anvin
2007-04-27 23:05             ` David Lang
2007-04-27 23:30             ` Ulrich Drepper
2007-04-27 23:33               ` H. Peter Anvin
2007-04-27  0:54   ` Ulrich Drepper
2007-04-27 15:27     ` Updated utimensat test program Ulrich Drepper
2007-04-27  1:57 ` [PATCH] utimensat implementation Neil Brown
2007-04-27  2:13   ` Ulrich Drepper
2007-04-27  6:01     ` Neil Brown
2007-05-10 18:26     ` Ulrich Drepper
2007-05-10 18:52       ` Christoph Hellwig
2007-05-10 19:44         ` Ulrich Drepper
2007-05-13 21:02           ` Christoph Hellwig
2007-05-11  1:01         ` H. Peter Anvin
2007-05-11  2:14       ` Neil Brown [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17987.53653.111396.778502@notabene.brown \ \ \ \ \ \
    --subject='Re: [PATCH] utimensat implementation' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).