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

Wichmann, Mats D mats.d.wichmann at intel.com
Thu Mar 6 22:23:36 PST 2008

[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 :-)

-----Original Message-----
From: lsb-discuss-bounces at lists.linux-foundation.org
[mailto:lsb-discuss-bounces at lists.linux-foundation.org] On Behalf Of
Stew Benedict
Sent: Thursday, March 06, 2008 4:22 AM
To: jrc at skylon.demon.co.uk
Cc: lsb-discuss at lists.linux-foundation.org
Subject: Re: [lsb-discuss] xfs fileystem fails tests passed by ext3 and

On Tue, 4 Mar 2008 jrc at skylon.demon.co.uk wrote:

> I have run a series of comparison 3.1.1 tests using the reiserfs,
> ext3, and xfs filesystems hosted on a SuSE SLES 10 SP1 system.  There
> are two test purposes that pass for ext3 and reiserfs but fail for
> Here is an excerpt from the journal of the xfs run:
> 10|77 /tset/POSIX.os/ioprim/write/T.write 13:52:33|TC Start, scenario
ref 80-0
> 15|77 3.6-lite 28|TCM Start
> [...]
> 400|77 15 1 13:53:34|IC Start
> 200|77 15 13:53:34|TP Start
> 520|77 15 00018119 1 1|time stamps incorrect: mtime, ctime were not
> 220|77 15 1 13:53:40|FAIL
> 410|77 15 1 13:53:40|IC End
> [...]
> 10|113 /tset/LSB.os/ioprim/writev_L/T.writev_L 14:03:41|TC Start,
scenario ref 119-0
> 15|113 3.6-lite 30|TCM Start
> [...]
> 400|113 15 1 14:04:41|IC Start
> 200|113 15 14:04:41|TP Start
> 520|113 15 00018514 1 1|time stamps incorrect: mtime, ctime were not
> 220|113 15 1 14:04:47|FAIL
> 410|113 15 1 14:04:47|IC End
> [...]
> Are these failures the result of a legitimate optimisation or is this
> a bug?  The xfs filesystem was mounted with the options set to
> "defaults".

These types of failures do tend to show up with different filesystems or

mount settings (noatime or nodiratime on ext3 will cause a number of

I'm not seeing anything in "man mount" about xfs defaults that implies 
that mtime, ctime would not be updated, but I also don't recall having
many tests on xfs systems.  It could well be that the test method needs
be reviewed to handle the various contemporary filesystems better.

Google does show old (2003) references to an xfs bug mentioning "XFS 
does not update directory mtime when changes made in directory", but
tests look to be creating/altering/checking only a file, not a

Stew Benedict
The Linux Foundation
lsb-discuss mailing list
lsb-discuss at lists.linux-foundation.org

More information about the lsb-discuss mailing list