xfs_logprint segfault with external log

[Alexander Tsvetkov]

On 02/17/2015 04:38 AM, Dave Chinner wrote:
> On Mon, Feb 16, 2015 at 04:55:14PM +0300, Alexander Tsvetkov wrote:
>> On 02/13/2015 02:09 AM, Dave Chinner wrote:
>>> On Thu, Feb 12, 2015 at 02:52:45PM +0300, Alexander Tsvetkov wrote:
>>>> 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:
>>> Please try the patch below, it fixes the problem on the image you
>>> provided.
>> I've restored provided image to filesystem with the same log file,
>> applied patch to latest xfsprogs and have stable pass runs
>> of xfs_logprint on that filesystem and running with xfsprogs without
>> this patch results to xfs_logprint segfaults reported that means
>> patch is working.
> Good.
>
>> The problem that it is not working for repeated test runs where
>> xfs_logprint still continue to report bad log data. It seems it is
> xfs_logprint is not a tool that is intended for validation of the
> log contents. It's a triage tool that was written in a hurry, and as
> such it's neither reliable or maintainable.  Indeed, there's a
> comment in the code saying it really needs to be rewritten. ;)
>
> I'll have a look the image, but really spending lots of time on
> fixing minor issues with logprint really isn't the best use of my
> time right now...
Thank you, really xfs_logprint was not a subject here. It's used by me
to understand xfs log data format to verify some cases related to xfs
log recovery functionality, just tried to simulate some cases with log 
corruptions
and have no expected specific xfs alert from the kernel source that I 
would like to
see for that test case. xfs journaling para is marked as TODO in 
documentation
currently,  so I thought xfs_logprint would put more clarity how xfs 
journal data
organized.
>
> Cheers,
>
> Dave.
Thanks,
Alexander Tsvetkov