Mounting the filesystem without the geometry doesn't change things, the size
is still wrongly reported for .db files.
I have however found files that should be 44 bytes (from ls -al) and
bacardi 0 # ls -al 000b21176cda012e1c0a7828f75347c3.289492.db
-rw------- 1 root root 44 Nov 2 20:18
000b21176cda012e1c0a7828f75347c3.289492.db
bacardi 0 # du -sk 000b21176cda012e1c0a7828f75347c3.289492.db
2147483532 000b21176cda012e1c0a7828f75347c3.289492.db
The value that du reports is the same as the one for 28-byte files, so it's
a constant, regardless of the real size of the file.
FWIW, this is a filesystem with a huge amount of files:
bacardi 0 # df -hi
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/root 8.0M 44K 8.0M 1% /
/dev/md0 12K 33 12K 1% /boot
/dev/md3 224M 11M 214M 5% /Storage
none 63K 1 63K 1% /dev/shm
I have requested my vendor to actually build a kernel with the most recent
patches + include the most recent userland progs. Could it be that a newer
version of xfs_repair might catch some inconsistencies the current version
would not ?
Kind regards,
Renaat
-----Original Message-----
From: Eric Sandeen [mailto:sandeen@xxxxxxx]
Sent: 01 November 2005 05:17
To: Renaat Dumon
Subject: RE: XFS corruption on 2.4.28
Renaat Dumon wrote:
> Hi Eric,
>
> Thanks for taking the time to look at this.
>
> bacardi root # xfs_info /Storage
> meta-data=/Storage isize=256 agcount=56, agsize=1048576
> blks
> = sectsz=512
> data = bsize=4096 blocks=58663328, imaxpct=25
> = sunit=0 swidth=0 blks, unwritten=0
> naming =version 2 bsize=4096
> log =internal bsize=4096 blocks=7161, version=1
> = sectsz=512 sunit=0 blks
> realtime =none extsz=65536 blocks=0, rtextents=0
FWIW I tried this test with stock 2.4.28:
[root@penguin5 src2]# mkfs.xfs -f -bsize=4096
-dfile,name=testfs,agsize=1048576b,size=58663328b,unwritten=0
meta-data=testfs isize=256 agcount=56, agsize=1048576
blks
= sectsz=512
data = bsize=4096 blocks=58663328, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=0
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=28644, version=1
= sectsz=512 sunit=0 blks
realtime =none extsz=65536 blocks=0, rtextents=0
[root@penguin5 src2]# mount -o loop,noatime,sunit=128,swidth=256 testfs
/mnt/test/
[root@penguin5 src2]# cd /mnt/test/
[root@penguin5 test]# ls
[root@penguin5 test]# echo abcdefghijklmnopqrstuvwxyza > file
[root@penguin5 test]# ls -l file
-rw-r--r-- 1 root root 28 Oct 31 22:03 file
[root@penguin5 test]# for a in `seq 1 3`; do for b in `seq 1 3`; do for c in
`seq 1 10000`; do mkdir -p $a/$b; cp file
$a/$b/00005d697a5a05795f53cb7b081f242d.$c.db; done; done; done
[root@penguin5 test]# find . | xargs du -sk | grep -v ^4
366124 .
122040 ./1
122040 ./2
122040 ./3
so that did not trip it. perhaps you could try a similar test with your
kernel.... either on loopback like this, or on your real filesystem?
Does the above tree structure / file naming more or less match your real
application?
-Eric
|