Re: xfs_logprint segfault with external log

From: Alexander Tsvetkov <alexander.tsvetkov@oracle.com>
To: Dave Chinner <david@fromorbit.com>, Eric Sandee <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com
Subject: Re: xfs_logprint segfault with external log
Date: Thu, 12 Feb 2015 14:52:45 +0300	[thread overview]
Message-ID: <54DC940D.4030009@oracle.com> (raw)
In-Reply-To: <20150211205406.GT4251@dastard>


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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs