xfs_logprint segfault with external log

[Alexander Tsvetkov]

archive with necessary data is available by this reference:

https://drive.google.com/open?id=0B1Cg0_B_ui2gRTQ1Yk9kVUw1Snc&authuser=0

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:
>>
>> "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.
Thanks,
Alexander Tsvetkov