On Thu, 20 Sep 2007 05:42:54 +1000, Eric Sandeen <sandeen@xxxxxxxxxxx>
wrote:
Jochen K. wrote:
[output with encryption]
mkfs.xfs -f /dev/mapper/raid6
meta-data=/dev/mapper/raid6 isize=256 agcount=32,
agsize=53412581
blks
= sectsz=512 attr=0
data = bsize=4096 blocks=1709202592,
imaxpct=25
= sunit=0 swidth=0 blks, unwritten=1
naming =version 2 bsize=4096
log =internal log bsize=4096 blocks=32768, version=1
= sectsz=512 sunit=0 blks, lazy-count=0
realtime =none extsz=4096 blocks=0, rtextents=0
b7f57ad0: Badness in key lookup (length)
bp=(bno 13673620728, len 131072 bytes) key=(bno 13673620728, len 4096
bytes)
What generates the last two lines in the above message, and do you know
what it indicates?
One problem I discovered with libxfs and repair in the prefetch is the
handling of I/O to a block offset, but with different I/O size.
libxfs cannot handle this, so I enabled IO_BCOMPARE_CHECK to detect
any I/Os that have the same offset but different length. This is a
bad thing for libxfs and it can lose data coherency.
I need to know what mkfs is doing at that offset. Probably the simplest
way is to enable IO_DEBUG, rebuild and observe all the I/Os to libxfs.
Since it's mkfs, there shouldn't be too many I/Os in total.
If you want to be clever, use XFS_BUF_TRACING with gdb, that will
pin-point the exact location :)
Regards,
Barry.
|