Re: XFS corruption on 2.4.28

[Eric Sandeen <sandeen@xxxxxxx>]

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