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:
>
> "Oper (307): tid: eec9b0c7 len: 16 clientid: TRANS flags: none
> EXTENTS inode data
> Oper (308): tid: 41000000 len: 805306368 clientid: ERROR flags: none
> LOCAL attr data
Clearly that operation is wrong, so everything past it is suspect.
This sort of error usually comes from an error parsing an earlier
ophdr, so even that probably doesn't point directly at the cause.
> ============================================================================
> cycle: 1 version: 2 lsn: 1,3138 tail_lsn: 1,2
> length of Log Record: 32256 prev offset: 3074 num ops: 375
> uuid: 39a962b7-4c0d-4e0e-8bcd-39471f93bc1d format: little endian linux
> h_size: 32768
> ----------------------------------------------------------------------------
> Oper (0): tid: eec9b0c7 len: 48 clientid: TRANS flags: none
> **********************************************************************
> * ERROR: data block=3138 *
> **********************************************************************
>
> xfs_logprint: unknown log operation type (2e00)
> Bad data in log"
i.e. this is not the problem that needs to be chased.
> Subsequent call to "xfs_repair -n -l $loopdev $SCRATCH_DEV" passes
> and filesystem is mounted without errors.
xfs_repair -n doesn't look at the log at all.
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
