xfs
[Top] [All Lists]

strange result of an XFS crash test

To: linux-xfs@xxxxxxxxxxx
Subject: strange result of an XFS crash test
From: Michal Szymanski <msz@xxxxxxxxxxxxxx>
Date: Wed, 27 Oct 2004 12:12:00 +0200
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.1i
Hi,

Experimenting on how reliable is XFS, I made a following test on my
Fedora Core 2 system, dual Xean 3.06GHz, Tyan Tiger i7501
mobo, 2.6.7-1.494.2.2smp kernel, xfsprogs-2.6.13-1:

On a just-below-2TB filesystem, I ran a script generating 4MB files
x.NNNNN, with NNNNN going from 00001 to 10000.

Just before the script ended, I did hardware reset and, on rebooting, I
chose "file system checking of an uncleanly shut system" that Fedora
offers at boot time.

I cound not see the XFS filesystem (/export/data2) being checked (it was
showing checking /, /usr and /export/data - all EXT3 filesystems).

After reboot, the root directory of the XFS partition looked a bit
strange. I would expect some problems with last-created files x.NNNNN 
It was, however, not quite so.

The last file present is x.09426. The first file with bad size
(3145728 instead of 4194304) is x.08165, with the creation date of about
2 minutes earlier than the last one. There is total of 61 files of bad
size, "randomly" distributed between x.08165 and x.09426. A short
excerpt from 'ls -l' output follows:

-rw-r--r--  1 root    bin   4194304 Oct 27 11:36 x.09403
-rw-r--r--  1 root    bin   2097152 Oct 27 11:36 x.09404
-rw-r--r--  1 root    bin         0 Oct 27 11:36 x.09405
-rw-r--r--  1 root    bin   4194304 Oct 27 11:36 x.09406
-rw-r--r--  1 root    bin   4194304 Oct 27 11:36 x.09407
-rw-r--r--  1 root    bin   4194304 Oct 27 11:36 x.09408
-rw-r--r--  1 root    bin         0 Oct 27 11:36 x.09409
-rw-r--r--  1 root    bin   4194304 Oct 27 11:36 x.09410
-rw-r--r--  1 root    bin   4194304 Oct 27 11:36 x.09411
-rw-r--r--  1 root    bin   3145728 Oct 27 11:36 x.09412
-rw-r--r--  1 root    bin         0 Oct 27 11:36 x.09413
-rw-r--r--  1 root    bin         0 Oct 27 11:36 x.09414
-rw-r--r--  1 root    bin         0 Oct 27 11:36 x.09415
-rw-r--r--  1 root    bin         0 Oct 27 11:36 x.09416
-rw-r--r--  1 root    bin         0 Oct 27 11:36 x.09417
-rw-r--r--  1 root    bin         0 Oct 27 11:36 x.09418
-rw-r--r--  1 root    bin   4194304 Oct 27 11:36 x.09419
-rw-r--r--  1 root    bin   4194304 Oct 27 11:36 x.09420

As I was not sure whether the FS had been really checked during the
reboot, I did xfs_repair manually, but nothing changed.

It that what I should expect from a journalling file system?

BTW, with a "standard" /etc/fstab entry:
  /dev/sda1   /export/data2  xfs   defaults    1 2
is it going to be checked/repaired if needed at boot time?
With EXT2/3 FS, "fsck" does both check and repair. With XFS, this job
seems to be splitted into xfs_check and xfs_repair? Is the system
"fsck" wrapper aware of that?

regards, Michal.

-- 
  Michal Szymanski (msz at astrouw dot edu dot pl)
  Warsaw University Observatory, Warszawa, POLAND


<Prev in Thread] Current Thread [Next in Thread>