I managed to find another systems had already occurred or not yet.
I changed the line for /Storage in /etc/fstab
From: /dev/md3 /Storage xfs rw,noatime,sunit=128,swidth=256 0 0
To: /dev/md3 /Storage xfs rw,noatime 0 0
Now waiting for some activity ...
Renaat
-----Original Message-----
From: Eric Sandeen [mailto:sandeen@xxxxxxx]
Sent: 31 October 2005 22:13
To: Renaat Dumon
Cc: linux-xfs@xxxxxxxxxxx
Subject: Re: XFS corruption on 2.4.28
Renaat Dumon wrote:
>
> I don't think I'm using extended attribs, I just do mkfs.xfs and mount
> :) And I don't know what xfs_fsr is :s I'm running a Gentoo kernel
> 2.4.28 , but I'm not sure of it's a stock one or not.
any chance you could try a stock kernel from 2.4.28, untouched by our
friends at gentoo.... ?
> I unmount/remounted the filesystem, and after a while the problem
> re-appears, albeit for other files. While the one previously mentioned
> is still good (for now anyway)
>
> One file:
> Another file:
Ok, no attributes.
And the "wrong" du output is always 0x7FFFFF8C in both cases, odd.
> I haven't tried mounting the filesystem without the geometry options,
> my solution vendor insists that these parameters are "performance
enhancing"
> and that the application involved is not guaranteed to work as well
> without these...
it will probably slow things down, yes... but that should be the worst of
it.
Depending on how easily/quickly you can normally reproduce, it might be a
good data point.
Alternatively, perhaps a test that replicates what your application is doing
could be devised to reproduce the problem... can you say which application
this is, or what its IO pattern looks like?
>
> The output of an xfs_repair is squeaky clean, but when I wait really
> long before doing an unmount/Remount, I get the move to lost+found again.
Well, xfs_repair should say -something- if it's going to move everything to
lost+found/ ....
> The hardware is just fine, I tried dd over & over again to check the
disks.
> I have 2 disks mirrored using mdadm.
>
> I just realized something you talking about small files,
>
> I have a dir structure [0-9a-f]/[0-9a-f]/[0-9a-f] where all these
> files reside. I did the following to easily detect which files were
> currently
> affected:
>
> bacardi 0 # du -sk * |sort -n
> < .. Cut .. >
> 2147483532 00005d697a5a05795f53cb7b081f242d.65536.db
...
> All these files should be 28 bytes !!!
And they are always reported as 2147483532 / 0x7FFFFF8C
Hmmmm... thinking.
-Eric
|