[lsb-discuss] xfs fileystem fails tests passed by ext3 and reiserfs?

Nick Stoughton nick at usenix.org
Fri Mar 7 15:09:51 PST 2008

On Fri, 2008-03-07 at 22:17 +0000, John Connett wrote:
> On Thu, 2008-03-06 at 22:23 -0800, Wichmann, Mats D wrote:
> > [apology: I just got my email system rebuilt by my IT people, data saved
> > but many "sanity settings" lost, since there's no quoting going on I
> > have to go ahead an accept the top-posting proposal...]
> > 
> > We have to do some work on the topic of file timestamps, and I'm
> > interested in hearing comments in general on this.  The "absolutism" of
> > the POSIX specification, which we inherit by reference, and which the
> > tests expect, does not seem to match the current world of Linux any
> > longer. In particular, Linux-on-laptops doesn't want to be updating
> > things so often, it's bad for battery life and storage media life,
> > neither of which have been prominent considerations in the development
> > of POSIX. I don't believe we have an LSB position on this, except the
> > general "things that Linux systems are doing as a matter of course
> > shouldn't just out-of-hand be considered wrong for being a little
> > different than POSIX".  POSIX is a very useful baseline for us, it has
> > better quality interface documentation than we can point at anywhere
> > else, but it's not god either, and our job is to describe common
> > implementation practice.
> > 
> > There could also be bugs in implementations, of course :-)
> It's been a while since I have worked on filesystem implementation but,
> from what I remember, there is a an important difference between the
> volatile state of the filesystem, where I would expect timestamps to be
> maintained in memory (low cost), and the state on stable storage (high
> cost).  Lost of clever stuff to reduce the number of writes to stable
> storage while maintaining a valid/recoverable filesystem!  And great
> care with clever devices that tell you that a write has happened when
> it's actually in a volatile cache while it juggles the order of
> writes ...
> The POSIX filesystem tests address the problem of correct behaviour at
> the API level.  A memory-based filesystem could pass these tests without
> any persistent storage.
Exactly. POSIX says nothing about when IO happens to the disk itself,
merely talking about consistency between when something is marked for
update and getting that data back. You could have a fully conforming
POSIX filesystem that actually does a huge amount of write caching (e.g.
it could only do disk updates once a day, and still conform).

The current words here say:

<quote src=austin-d4r>
An implementation may update timestamps that are marked for update
immediately, or it may update such timestamps periodically. At the point
in time when an update occurs, any marked timestamps shall be set to the
current time and the update marks shall be cleared. All timestamps that
are marked for update shall be updated when the file ceases to be open
by any process or before a stat( ), fstat( ), lstat( ), fsync( ),
futimens( ), utime( ), utimensat( ), or utimes( ) is successfully
performed on the file. Other times at which updates are done are

Nothing very absolute about that ... so I don't see why the tests are
failing (but I haven't looked at what they are doing).

And, as Andrew points out, having a file system that doesn't conform
does not mean in and of itself that the system is non-conforming. So
long as there is a documented way to get to a conforming environment.

> Testing the stable storage behaviour of a filesystem is a lot more
> tricky and probably outside the scope of LSB.  Dawson Engler has done
> interesting work with EXE; eXplode; and "disk images of death"
> (http://www.stanford.edu/~engler/).
> On a different tack, is the filesystem used recorded during the
> certification process?
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss

More information about the lsb-discuss mailing list