xfs
[Top] [All Lists]

Re: [PATCH] xfstests: fix internal _xfs_check to handle logdev etc

To: "Michael L. Semon" <mlsemon35@xxxxxxxxx>
Subject: Re: [PATCH] xfstests: fix internal _xfs_check to handle logdev etc
From: Eric Sandeen <sandeen@xxxxxxxxxx>
Date: Thu, 02 May 2013 15:48:35 -0500
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, sekharan@xxxxxxxxxx, xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <5182CE0D.8030502@xxxxxxxxx>
References: <51827DDF.4050708@xxxxxxxxxx> <1367509132.4098.86.camel@xxxxxxxxxxxxxxxxxx> <51828F84.3040508@xxxxxxxxxxx> <1367516658.4098.87.camel@xxxxxxxxxxxxxxxxxx> <5182B0FE.4030301@xxxxxxxxxxx> <5182CE0D.8030502@xxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
On 5/2/13 3:35 PM, Michael L. Semon wrote:
> On 05/02/2013 02:31 PM, Eric Sandeen wrote:
>> On 5/2/13 12:44 PM, Chandra Seetharaman wrote:
>>> On Thu, 2013-05-02 at 11:08 -0500, Eric Sandeen wrote:
>>>> On 5/2/13 10:38 AM, Chandra Seetharaman wrote:
>>>>> On Thu, 2013-05-02 at 09:53 -0500, Eric Sandeen wrote:
>>>>>> Pull all of the old xfs_check script into common/rc:_xfs_check()
>>>>>> so that it properly handles all options, including external log
>>>>>> devices.
>>>>>
>>>>> I see changes only related to USAGE. iiuc, log devices are handled
>>>>> properly by current code.
>>>>
>>>> also:
>>>>
>>>>>> +    set -- extra $@
>>>>>> +    shift $OPTIND
>>>>
>>>> have you *tested* log devices w/ your original code?  It failed for
>>>> Michael and for myself, so...  ;)
>>>>
>>>> -Eric
>>>
>>> yikes. sorry :(
> 
> No worries, Chandra.  I couldn't even get the echo line for Eric's patched 
> version and execute the script in the same pass.  There's something about 
> debugging the passing of arguments in bash that is simply evil.
> 
>> It's ok - I reviewed it, but I didn't test it.  ;)  It happens.
>>
>> -Eric
>>
> 
> Oh, so leave it to me to hack my lone swap partition on this PC into a 
> two-segment dm-linear device so I can test this...OK...that was successful 
> for a change!  Even though `git am` complained about the whitespace (E-mail 
> issue?), the patch worked as well.
> 
> Anyway, there are issues with these tests and whether the partitions are 
> mounted at the time ./check is run, but that will be posted after my closing, 
> just to put it out there that issues may exist in the mount checking.  [And 
> I'm sure that I did an `export USE_EXTERNAL="yes"`, so it's surprising how 
> the tests went about mounting.]
> 
> =====================================================================
> This is how things went before using Eric's patch:
> 
> root@plbearer:/var/lib/xfstests# ./check generic/001
> mount: wrong fs type, bad option, bad superblock on /dev/mapper/tData,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> 
> common/rc: retrying test device mount with external set
> FSTYP         -- xfs (non-debug)
> PLATFORM      -- Linux/i686 plbearer 3.8.11
> 
> _check_xfs_filesystem: filesystem on /dev/mapper/tData is inconsistent (c) 
> (see .full)
> Passed all 0 tests
> root@plbearer:/var/lib/xfstests# cat .full
> _check_xfs_filesystem: filesystem on /dev/mapper/tData is inconsistent
> *** xfs_check output ***
> Usage: xfs_check [-ifFrxV] [-p prog] [-l logdev] [-c cmd]... device
> *** end xfs_check output
> *** mount output ***
> /dev/sda1 on / type xfs (rw,uquota)
> proc on /proc type proc (rw)
> sysfs on /sys type sysfs (rw)
> /dev/sda6 on /alt_sys type xfs (ro)
> tmpfs on /dev/shm type tmpfs (rw)
> debugfs on /sys/kernel/debug type debugfs (rw)
> /dev/sdb1 on /media/uGeneral type f2fs (rw)
> *** end mount output
> 
> Here is the echo line of what command was run:
> /usr/sbin/xfs_db -l /dev/mapper/tLog -F -i -p xfs_check -c check 
> -l/dev/mapper/tLog
> 
> =====================================================================
> This is how things went after using Eric's patch:
> 
> root@plbearer:/var/lib/xfstests# ./check generic/001
> mount: wrong fs type, bad option, bad superblock on /dev/mapper/tData,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so

Yeah this seems . . . suboptimal, I haven't looked into it.

If TEST_LOGDEV is set it seems like that should be the *first* thing
to try.  I don't recall if it did this before the reorganization.

FWIW, I've seen problems in the past when using devicemapper devices.
One never knows what's a symlink ;)

If you specify /dev/dm-X instead of the pretty name, does it go any
better for you?

(I don't remember if that helped; I remember chasing dm issues before.
I just don't use dm in my testing anymore, TBH) :)

-Eric

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