xfs
[Top] [All Lists]

RE: XFS corruption on 2.4.28

To: "'Eric Sandeen'" <sandeen@xxxxxxx>
Subject: RE: XFS corruption on 2.4.28
From: "Renaat Dumon" <renaat.dumon@xxxxxxxxxx>
Date: Wed, 2 Nov 2005 22:39:50 +0100
Cc: <linux-xfs@xxxxxxxxxxx>
In-reply-to: <Pine.LNX.4.44.0510312216420.26145-100000@penguin.americas.sgi.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
Thread-index: AcXemxon+DTwCBFeQgq6VmfLEgptkABWY0jw
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



<Prev in Thread] Current Thread [Next in Thread>