On 02/17/2015 04:38 AM, Dave Chinner wrote:
On Mon, Feb 16, 2015 at 04:55:14PM +0300, Alexander Tsvetkov wrote:
On 02/13/2015 02:09 AM, Dave Chinner wrote:
On Thu, Feb 12, 2015 at 02:52:45PM +0300, Alexander Tsvetkov wrote:
On 02/11/2015 11:54 PM, Dave Chinner wrote:
On Wed, Feb 11, 2015 at 04:51:44PM +0300, Alexander Tsvetkov wrote:
Hello,
I've obtained corrupted xfs log after some sanity xfs testing:
"log=logfile
log_size=855
dd if=/dev/zero "of=$log" bs=4096 count=$log_size
loopdev=$(losetup -f)
losetup $loopdev $log
mkfs.xfs -f -m crc=1 -llogdev=$loopdev,size=${log_size}b $SCRATCH_DEV
mount -t xfs -ologdev=$loopdev $SCRATCH_DEV $SCRATCH_MNT
./fdtree.sh -l 4 -d 4 -C -o $SCRATCH_MNT
sync
umount $SCRATCH_MNT
xfs_logprint -l $loopdev $SCRATCH_DEV"
Test makes crc enabled xfs filesystem with the external log of
minimal allowed size and then creates on this fs the small directory
tree
with sub directories and files of fixed depth and size with help of
fdtree utility:
https://computing.llnl.gov/?set=code&page=sio_downloads
Just take metadump image and put it somewhere we can down load it.
After that xfs_logprint stably reports bad data in log:
Please try the patch below, it fixes the problem on the image you
provided.
I've restored provided image to filesystem with the same log file,
applied patch to latest xfsprogs and have stable pass runs
of xfs_logprint on that filesystem and running with xfsprogs without
this patch results to xfs_logprint segfaults reported that means
patch is working.
Good.
The problem that it is not working for repeated test runs where
xfs_logprint still continue to report bad log data. It seems it is
xfs_logprint is not a tool that is intended for validation of the
log contents. It's a triage tool that was written in a hurry, and as
such it's neither reliable or maintainable. Indeed, there's a
comment in the code saying it really needs to be rewritten. ;)
I'll have a look the image, but really spending lots of time on
fixing minor issues with logprint really isn't the best use of my
time right now...
Thank you, really xfs_logprint was not a subject here. It's used by me
to understand xfs log data format to verify some cases related to xfs
log recovery functionality, just tried to simulate some cases with log
corruptions
and have no expected specific xfs alert from the kernel source that I
would like to
see for that test case. xfs journaling para is marked as TODO in
documentation
currently, so I thought xfs_logprint would put more clarity how xfs
journal data
organized.
Cheers,
Dave.
Thanks,
Alexander Tsvetkov
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
