xfs_logprint segfault with external log

[Dave Chinner]

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 at fromorbit.com