linux-kernel - Re: [PATCH] utimensat implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <17987.53653.111396.778502@notabene.brown>
Date:	Fri, 11 May 2007 12:14:45 +1000
From:	Neil Brown <neilb@...e.de>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	Christoph Hellwig <hch@...radead.org>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] utimensat implementation

On Thursday May 10, drepper@...hat.com 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
  /sysfs/filesystem/00:03/....

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

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?

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/