Renaat Dumon wrote:
A couple questions early on - is this stock 2.4.28 from kernel.org?
Are you using extended attributes? Have you run xfs_fsr on this filesystem?
I doubt that fsr is the culprit here, because your files are only 28 bytes
long, so fsr would not touch them.
When I then cd into 0/0/0 and I do a 'du -sk *' :
0x7FFFFF8C - hm, a lot of binary 1's in there...
bacardi 0 # ls -al 000fe1c2b17a7b4b4d2c4eea341cfb08.65536.db
-rw------- 1 root root 28 Oct 30 18:53
can you try an xfs_bmap -v, and xfs_bmap -a -v of this file? Just out of
The correct filesize is indeed 28 bytes! The file mentioned here is just an
example, but there are quite some files like that actually :(
It might be interesting to gather the reported/correct values for several
files, so we can possibly identify a pattern.
Unmounting/remounting the filesystem makes the issue go away temporarily, it
is back after a couple of hours of operation.
so a file which shows up as bad is ok after a remount? So at least this
problem is not on-disk, but...
I did a xfs_check / xfs_repair before ; but that just dumped (ALMOST)
EVERYTHING in lost+found , so I'm losing data :(
... something -is- bad on disk. What is the output of xfs_repair?
The fact that I'm having this on multiple systems is what worries me, the
filesystems are created with default options, but are mounted with
what volume manager are you using?
Can you verify whether using the stripe geometry contributes to the problem?
Without su,sw does the problem go away?
Does this sound familiar to any of you ? Thanks a bunch!
not quite, the last du reporting problem was only on files with extended
attributes, and only after an xfs_fsr run - but in your case the files are
small enough that fsr probably ignores them.