[Top] [All Lists]

Re: xfs_logprint segfault with external log

To: Dave Chinner <david@xxxxxxxxxxxxx>, Eric Sandee <sandeen@xxxxxxxxxxx>
Subject: Re: xfs_logprint segfault with external log
From: Alexander Tsvetkov <alexander.tsvetkov@xxxxxxxxxx>
Date: Thu, 12 Feb 2015 14:52:45 +0300
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150211205406.GT4251@dastard>
References: <54DB5E70.80607@xxxxxxxxxx> <20150211205406.GT4251@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

archive with necessary data is available by this reference:


On 02/11/2015 11:54 PM, Dave Chinner wrote:
On Wed, Feb 11, 2015 at 04:51:44PM +0300, Alexander Tsvetkov wrote:

I've obtained corrupted xfs log after some sanity xfs testing:


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

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
with sub directories and files of fixed depth and size with help of
fdtree utility:
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.


Alexander Tsvetkov

<Prev in Thread] Current Thread [Next in Thread>