Re: bad block number and bad nblocks after simple file operations.

[Pavel Kiryukhin <savl@xxxxxxxxxxxxx>]

Eric Sandeen wrote:

> Looks like maybe some platform/endian issues.

Yes! It looks like that:
platform: - there is no problem with ARM LE and the same kernel + XFS 
version (1.3)
endian: more complicated. for both BE and LE tests like bonnie++ are 
passed. Bad things happens in case of, say, system crash. For MIPS LE fs 
can not recovered.
This was tested on two different mips LE boards.

Currently I found that bmx field of inode get corrupted (all tests for 
mips le):
xfs_db> blockget -n
inode 132 bad block number -1 [0,-1], offset 0
bad nblocks 1 for inode 132, counted 0
block 0/12 type unknown not expected
xfs_db> ncheck
       131 nullfile
       132 testfile
xfs_db> agf 0
xfs_db> inode 132
xfs_db> p core.size
core.size = 120
xfs_db> p u.bmx
u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,0,0,0]
-------
Here I don't understand how fs contines to operate (open and read) with 
this file? It looks like some cache issues:

I create file with size 0. blockget -n does not complain.
I write to this file 2 bytes, blockget -n does not complain.
I leave xfs_db, issue sync twice - have
xfs_db> blockget -n
inode 131 bad block number -1 [0,-1], offset 0
bad nblocks 1 for inode 131, counted 0
block 0/12 type unknown not expected
xfs_db> q
root@xxxxxxxxxxxxx:/mnt# cat /mnt/xfs/testfile
t
root@xxxxxxxxxxxxx:/mnt# umount /mnt/xfs/
root@xxxxxxxxxxxxx:/mnt# mount /dev/ide/host0/bus0/target0/lun0/part1 
/mnt/xfs/
XFS mounting filesystem ide0(3,1)
root@xxxxxxxxxxxxx:/mnt# cat ./xfs/testfile
root@xxxxxxxxxxxxx:/mnt#
root@xxxxxxxxxxxxx:/mnt# ls -l ./xfs/
total 4
-rw-r--r--    1 root     root            2 Jan  1 00:39 testfile
----------
Actually I get my 2 bytes corrupted.

> How big is your filesystem?  (xfs_info /mount/point)

Here is fs on 40G IDE disk:
--------------
meta-data=/mnt/xfs               isize=256    agcount=38, agsize=262144 blks
        =                       sectsz=512
data     =                       bsize=4096   blocks=9769520, imaxpct=25
        =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=4770, version=1
        =                       sectsz=512   sunit=0 blks
realtime =none                   extsz=65536  blocks=0, rtextents=0
-------------
the similar results are for 100 mb loop file.

> Below, those block numbers look very big, as do the AG numbers 
> (6291456,6815744) 

Yes, for LE block numbers are negative.

> Can you try more recent XFS code?  Where'd the XFS code come from?  
> I'd suggest getting XFS from CVS if you can, just to make sure we're 
> not chasing old bugs. 

Well, I'm using 1.3.1 version now. The same problem can be reproduced 
for 1.3.
---
As I am totally new to xfs could you please recommend the place to start 
looking at. Even general hints like "buffer cache" will be highly 
appreciated!
-------
Thank you,
Pavel Kiryukhin

> -Eric
>
> Pavel Kiryukhin wrote:
>
> > Hi,
> > can anybody help me and answer:  is it  normal XFS behavior or 
> > something is terribly wrong?
> >
> > 1) I have created and mounted xfs using loop device and NFS (with IDE 
> > disk results are generally the same),
> > 2) created file "testfile", directoty "tesdir" and file "testfile"1 
> > in it.
> > 3) unmounted xfs and started xfs_db
> >
> > xfs_db> blockget -n
> > inode 132 bad block number 3870332469381120 [6291456,2048], offset 
> > 4238657
> > bad nblocks 1 for inode 132, counted 0
> > inode 134 bad block number 1759274439018496 [6815744,2048], offset 
> > 4238659
> > bad nblocks 1 for inode 134, counted 0
> > block 0/12 type unknown not expected
> > block 0/13 type unknown not expected
> > xfs_db> ncheck
> >        131 testdir/.
> >        132 testfile
> >        134 testdir/testfile1
> > xfs_db> log stop
> >
> > After that I can mount again and work with XFS, read/write/create 
> > files etc.
> > My platform is MIPS (LE and BE), 2.4.20 kernel
> > --
> > Thank you,
> > Pavel Kiryukhin