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
|