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
|