public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael L. Semon" <mlsemon35@gmail.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Eric Sandeen <sandeen@redhat.com>,
	sekharan@us.ibm.com, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfstests: fix internal _xfs_check to handle logdev etc
Date: Thu, 02 May 2013 16:35:25 -0400	[thread overview]
Message-ID: <5182CE0D.8030502@gmail.com> (raw)
In-Reply-To: <5182B0FE.4030301@sandeen.net>

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

common/rc: retrying test device mount with external set
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/i686 plbearer 3.8.11

generic/001      7s
Ran: generic/001
Passed all 1 tests

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 
/dev/mapper/tData

=====================================================================

Anyway, thanks for the patch!  It will put me back on track.  This 
xfstests restructuring looks like a significant undertaking, and issues 
along the way are expected.

Good luck!

Michael

=====================================================================
P.S. - This is what three passes in a row looks like, using Eric's 
patched version of ./check:

RUN #1
root@plbearer:/var/lib/xfstests# mount | grep mapper

root@plbearer:/var/lib/xfstests# ./check -xfs generic/001 generic/002
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

generic/001      7s
generic/002      0s
Ran: generic/001 generic/002
Passed all 2 tests

RUN #2
root@plbearer:/var/lib/xfstests# mount | grep mapper
/dev/mapper/tData on /mnt/testdir type xfs (rw,logdev=/dev/mapper/tLog)

root@plbearer:/var/lib/xfstests# ./check -xfs generic/001 generic/002
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/i686 plbearer 3.8.11

_check_xfs_filesystem: filesystem on /dev/mapper/tData has dirty log 
(see .full)
_check_xfs_filesystem: filesystem on /dev/mapper/tData is inconsistent 
(c) (see .full)
_check_xfs_filesystem: filesystem on /dev/mapper/tData is inconsistent 
(r) (see .full)
Passed all 0 tests

RUN #3
root@plbearer:/var/lib/xfstests# mount | grep mapper

root@plbearer:/var/lib/xfstests# ./check -xfs generic/001 generic/002
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

generic/001      7s
generic/002      1s
Ran: generic/001 generic/002
Passed all 2 tests

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

  reply	other threads:[~2013-05-02 20:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-02 14:53 [PATCH] xfstests: fix internal _xfs_check to handle logdev etc Eric Sandeen
2013-05-02 15:38 ` Chandra Seetharaman
2013-05-02 16:08   ` Eric Sandeen
2013-05-02 17:44     ` Chandra Seetharaman
2013-05-02 18:31       ` Eric Sandeen
2013-05-02 20:35         ` Michael L. Semon [this message]
2013-05-02 20:48           ` Eric Sandeen
2013-05-02 21:54             ` Michael L. Semon
2013-05-02 21:58               ` Eric Sandeen
2013-05-03 16:09 ` Rich Johnston

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5182CE0D.8030502@gmail.com \
    --to=mlsemon35@gmail.com \
    --cc=sandeen@redhat.com \
    --cc=sandeen@sandeen.net \
    --cc=sekharan@us.ibm.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox