[lsb-discuss] Adding statfs interfaces

Theodore Tso tytso at mit.edu
Fri Dec 15 19:45:50 PST 2006

On Fri, Dec 15, 2006 at 02:33:23PM -0800, Wichmann, Mats D wrote:
> Yes, in this case we do know that.
> statfs was deprecated in 1.3, and removed in 2.0, in favor
> of the POSIX-standard statvfs interfaces, which give all
> the information you mention.  What was missed (or we thought
> it wasn't a big deal), is that there's one bit of information
> statvfs doesn't give you that seems to be important - the
> file system type.  

My bad; sorry, I didn't have the context.

> Several people have told us quite vocally
> that they need to know this so that they know that expected
> locking operations and perhaps some others like synchronous
> writes may not behave the same on certain foreign filesystem
> types as on native linux filesystems, and that the apps
> actually need to know this.

One potential problem though is that if we have applications depending
on these sorts of things, wouldn't they be violating the fundamental
spirit of being an LSB compliant application?  Since we don't document
the specific implementation details of each filesystem, an application
which depends on that sort of behavior, or worse yet, uses filesystem
specific ioctl's, it wouldn't be very portable.

If we support this, the other concern is what would it mean if Solaris
or *BSD or MacOS to provide a LSB platform; could it be done?

What sorts of behaviors are these applications most concerned about?
Is there some way we can formally document what they are?

On Fri, Dec 15, 2006 at 03:40:35PM -0800, Nick Stoughton wrote:
> On Fri, 2006-12-15 at 23:56 +0100, Joerg Schilling wrote:
> > >From Solaris man statvfs:
> > 
> Solaris has extended the statvfs structure (as POSIX permits) to include
> f_basetype and f_fstr (and f_filler). Linux has not made these
> extensions. I would strongly encourage the kernel team to do this, but
> ultimately, the LSB describes what *is*, not what *should be* there!

The problem is that we don't have a lot of free space in the
kernel<->userspace data structure.  We currently only have 20 bytes of
"f_filler" space (we call it f_spare).  I could imagine trying to
convince folks to use 12 of those bytes for f_basetype, but it means
chewing up a lot of the rest of spare space --- and after that we
would have to allocate two new system calls.  

The other choice would be to depend on f_type and make allow glibc to
map f_type to f_basetype information via an extended form of
/proc/filesystems which includes the *_SUPER_MAGIC information.  The
problem with that scheme is that adding a 3rd field to
/proc/filesystems could potentially break some users of
/proc/filesystems not expecting it, and right now there isn't a
guarantee that all filesystems have a unique f_type assignment.  (For
all identical, which means it's not possible to determine whether a
filesystem is mounted as ext2, ext3, or ext4 --- which can be
important if an application needs to know what ioctl's are available
to it.  Of course, an application who wanted to know this wouldn't be
an LSB compliant application, and it wouldn't be very portable.)

						- Ted

More information about the lsb-discuss mailing list