[lsb-discuss] statfs specification addition: review
Camp, TracyX E
tracyx.e.camp at intel.com
Thu Dec 21 11:31:23 PST 2006
>Agreed, this is definitely a much better way to proceed in terms of
>long-term portability is concerned. And, there is actually a standard
>interface defined in Posix for this pathconf/fpathconf(). The
>question is what semantics do application vendors want to test for?
What I'm saying is that somebody (probably somebody that is a Linux VFS
maintainer) needs to sit down and think hard about what are optional
semantics and what are required semantics. Optional semantics might
include the ability to write to a file system, O_DIRECT opens, while
open for read I/O might be required of all file systems. Other
semantics like 'is this a network file system' or 'is this a cluster
file system' might be more general and less-well defined since they
actually represent attributes of the backing datastore for the file
system. However even these can be broken down into concrete terms like
'reliability', 'performance' (network file systems generally not be
great places to write large amounts of temporary data too), 'mmap()
coherency', 'flock coherency'. By making it the responsibility of the
file system implementation to describe its capabilities, it takes some
of the guesswork and portability issues out of the applicaiton layer.
Probably each of the VFS interfaces can and should define one or more
We used to have code that switched between our own file system magic and
2 other magic flavors that our file system might have to lie about due
to applicaitons that we where semantically compatible with looking for
magic strings like 'O','C','F','S'.
>> 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.
>Sure, assuming that we've also added the xattr interfaces into the LSB.
I'd think this is a more general problem than LSB, even source-code only
applications will eventually age-out if they have things that optionally
depend on XFS,EXT3 features and XFS and EXT3 both disappear from common
usage. File systems in Linux have a really short life span when you
compare against UFS, FAT and NTFS historically.
More information about the lsb-discuss