All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael L. Semon" <mlsemon35@gmail.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Eric Sandeen <sandeen@sandeen.net>,
	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 17:54:35 -0400	[thread overview]
Message-ID: <5182E09B.7070109@gmail.com> (raw)
In-Reply-To: <5182D123.80005@redhat.com>

On 05/02/2013 04:48 PM, Eric Sandeen wrote:
>> =====================================================================
>> 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

Ugh, that was a rather sobering experience.  Lesson learned.  To use 
/dev/dm-X goes much worse.  The /dev/dm-0 for logdev goes untranslated, 
but the /dev/dm-1 seems to get auto-translated back to /dev/mapper/tData 
(more commentary after this):

======================================================================
root@plbearer:~# export TEST_DEV=/dev/dm-1
root@plbearer:~# export TEST_LOGDEV=/dev/dm-0
root@plbearer:~# export USE_EXTERNAL="yes"
root@plbearer:~# cd /var/lib/xfstests/

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 generic/001 generic/002
mount: /dev/mapper/tData already mounted or /mnt/testdir busy
mount: according to mtab, /dev/mapper/tData is already mounted on 
/mnt/testdir
common/rc: retrying test device mount with external set
mount: /dev/mapper/tData already mounted or /mnt/testdir busy
mount: according to mtab, /dev/mapper/tData is already mounted on 
/mnt/testdir
common/rc: could not mount /dev/dm-1 on /mnt/testdir

root@plbearer:/var/lib/xfstests# ./check generic/001 generic/002
mount: /dev/mapper/tData already mounted or /mnt/testdir busy
mount: according to mtab, /dev/mapper/tData is already mounted on 
/mnt/testdir
common/rc: retrying test device mount with external set
mount: /dev/mapper/tData already mounted or /mnt/testdir busy
mount: according to mtab, /dev/mapper/tData is already mounted on 
/mnt/testdir
common/rc: could not mount /dev/dm-1 on /mnt/testdir

root@plbearer:/var/lib/xfstests# umount $TEST_DEV

root@plbearer:/var/lib/xfstests# ./check generic/001 generic/002
common/rc: Error: $TEST_DEV (/dev/dm-1) is not a MOUNTED xfs filesystem
Filesystem     Type 1K-blocks  Used Available Use% Mounted on
-              -       385460     0    385460   0% /dev

root@plbearer:/var/lib/xfstests# ./check generic/001 generic/002
mount: /dev/mapper/tData already mounted or /mnt/testdir busy
mount: according to mtab, /dev/mapper/tData is already mounted on 
/mnt/testdir
common/rc: retrying test device mount with external set
mount: /dev/mapper/tData already mounted or /mnt/testdir busy
mount: according to mtab, /dev/mapper/tData is already mounted on 
/mnt/testdir
common/rc: could not mount /dev/dm-1 on /mnt/testdir

root@plbearer:/var/lib/xfstests# umount $TEST_DEV

root@plbearer:/var/lib/xfstests# mount -t xfs -o logdev=$TEST_LOGDEV 
$TEST_DEV $TEST_DIR

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

root@plbearer:/var/lib/xfstests# echo $TEST_DEV
/dev/dm-1

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

So I got rid of the linear objects, went to cfdisk, brewed up some 
good-old-fashioned MBR logical partitions, and then...

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

root@plbearer:~# mkfs.xfs -l logdev=/dev/sda5 /dev/sda6
meta-data=/dev/sda6              isize=256    agcount=4, agsize=69774 blks
          =                       sectsz=512   attr=2, projid32bit=0
data     =                       bsize=4096   blocks=279095, imaxpct=25
          =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =/dev/sda5              bsize=4096   blocks=16057, version=2
          =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

root@plbearer:~# export TEST_DEV=/dev/sda6
root@plbearer:~# export TEST_LOGDEV=/dev/sda5
root@plbearer:~# export TEST_DIR=/mnt/testdir
root@plbearer:~# export USE_EXTERNAL="yes"
root@plbearer:~# cd /var/lib/xfstests/

root@plbearer:/var/lib/xfstests# ./check generic/001 generic/002
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
root@plbearer:/var/lib/xfstests# ./check generic/001 generic/002
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/i686 plbearer 3.8.11

generic/001      6s
generic/002      1s
Ran: generic/001 generic/002
Passed all 2 tests
root@plbearer:/var/lib/xfstests# ./check generic/001 generic/002
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

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

And here's how it runs on bare partitions after reversing the patch and 
reinstalling xfstests, as a sort of check figure...

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

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

_check_xfs_filesystem: filesystem on /dev/sda6 is inconsistent (c) (see 
.full)
Passed all 0 tests
root@plbearer:/var/lib/xfstests# ./check generic/001 generic/002
FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/i686 plbearer 3.8.11

_check_xfs_filesystem: filesystem on /dev/sda6 is inconsistent (c) (see 
.full)
Passed all 0 tests

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

So I'll consider this problem solved as well as another trial-by-fire 
lesson in using the device-mapper objects.  Thanks again!

Michael

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

  reply	other threads:[~2013-05-02 21:54 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
2013-05-02 20:48           ` Eric Sandeen
2013-05-02 21:54             ` Michael L. Semon [this message]
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=5182E09B.7070109@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.