[lsb-discuss] statfs specification addition: review

Camp, TracyX E tracyx.e.camp at intel.com
Thu Dec 21 09:06:13 PST 2006

To bring up an alternate suggestion...  It may be _entirely more_
controversial to introduce an entirely new interface, but the problem
that applications are trying to solve here is to determine file system
semantics, not the actual file system name, so why not push for an
interface that actually solves the real problem?  The file system magic
or name string should really just be advisory information.

The NT file system interface exposes a bitmask of attribute flags that
define various optional semantics (optional in the context of the NT
operating system that is... Linux has fewer optional semantics).  Things
for file systems by name (which sadly many applications do anyways) it
it possible to look for file systems by the feature that you are
actually interested in. In the case of Linux this is almost always
locking and cache coherency semantics (i.e. is it NFS?).  But Linux also
optionally supports a number of other optional file system semantics
like xattrs etc, that an application my be interested in.  This would
solve the relatively 'short' life span of file systems in Linux.  So
instead of searching for XFS's magic only to have the app break when
'TVFS3' comes along and supports xattrs, it could  be file system
agnostic in a safe manner.

Tracy Camp

>-----Original Message-----
>From: lsb-discuss-bounces at lists.freestandards.org 
>[mailto:lsb-discuss-bounces at lists.freestandards.org] On Behalf 
>Of Theodore Tso
>Sent: Thursday, December 21, 2006 8:56 AM
>To: Robert Schweikert
>Cc: lsb-discuss at freestandards.org
>Subject: Re: [lsb-discuss] statfs specification addition: review
>Well, let's see how much support we get from the kernel development
>community, first.  People very strongly dislike magic numbers, and the
>current one clearly doesn't work (because there are no guarantees of
>uniqueness and ext2/3/4 already share the same magic number).  If we
>use a magic number, then it will have to be a new one, and people will
>have to register it to avoid conflicts, and I'm pretty sure I know
>what response that will get from Linus (BZZT!).  
>On the other hand, if we use a character string, we don't have a lot
>of extra space available in the interface as defined by the current
>set of fsystem calls --- which is DIFFERENT from the structures used
>by (f)statvfs(64) or (f)statfs(64).  
>My current thinking is to propose using an 8 byte fixed length string
>(which uses up 2 out of the 5 available 32-bit spare fields in the
>kernel statfs structure), with a registry in
>/usr/src/linux/Documentation to avoid collisions, and see if we can
>get consensus on LKML around that.
>Once we get this into the kernel, then the next step will get glibc to
>change (f)statvfs(64) to use one of its spare fields to send back the
>8 byte fixed character string.  And then of course, the 12-18 month
>wait until the distributions pick up the changes from glibc.
>I'm willing to take on the task of writing up the necessary kernel
>patch and trying to shepherd them through LKML, if we have consensus
>that this will solve the problem in the best possible way.  (If we had
>the space, I'd love to be able to enhance statvfs() also pass back the
>label and uuid information, but unfortunately, that doesn't seem to be
>very likely without the creation of two new system calls and a lot of
>backwards compatibility gorp.  Since that's not LSB-related, folks who
>want that should contact me off-line, and try to convince me that's
>going to be worth the work; we may be better off simply standardizing
>the blkid library interfaces instead.)
>Comments, thoughts?
>						- Ted
>lsb-discuss mailing list
>lsb-discuss at lists.freestandards.org

More information about the lsb-discuss mailing list