Re: How to run xfstests against multipath disks on SuSE?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/27/2012 02:37 PM, Eric Sandeen wrote:
On 11/27/12 2:35 PM, Dave Chinner wrote:
On Tue, Nov 27, 2012 at 11:08:30AM -0600, Eric Sandeen wrote:
On 11/26/12 9:14 PM, Dave Chinner wrote:
On Tue, Nov 27, 2012 at 09:20:47AM +0800, Ryan Wang wrote:
2012/11/26 Theodore Ts'o <tytso@xxxxxxx>:
On Mon, Nov 26, 2012 at 02:43:40PM +0100, Lukáš Czerner wrote:
The I checked the script common.rc, and found that it uses
df to determine the filesystem type and it uses the realpath
"/dev/dm-0" instead of "/dev/mapper/mpatha", while df always
shows "devtmpfs" instead of "ext4" for /dev/dm-0.

I run "mount" and found that devtmpfs is mount on /dev/ on opensuse
***by default***. Even though  I run "mount -t btrfs /dev/dm-0 /somedir",
df still showed devtmpfs.

Any ideas to kick off the xfstests?

At least with the df which ships with Debian Testing, df will display
the file system in use if it matches the device name which is
/etc/mtab.  It looks the issue is that mount is canonicalizing the
device name to be the human friendly version:

# ls -l /dev/mapper/closure-bigscratch
0 lrwxrwxrwx 1 root root 7 Nov 16 15:15 /dev/mapper/closure-bigscratch -> ../dm-7
<tytso.root@closure> {/home/tytso/bin}, level 2
# mount /dev/dm-7 /u2
# df /u2
Filesystem                     1K-blocks   Used Available Use% Mounted on
/dev/mapper/closure-bigscratch  52403200 224772  52178428   1% /u2
# grep /u2 /etc/mtab
/dev/mapper/closure-bigscratch /u2 xfs rw,relatime,attr2,inode64,noquota 0 0

So the simplest solution is to just use /dev/mapper/mpatha instead of
insisting on using /dev/dm-0.  That's what I do....

In xfstests/common.rc, it will use realpath to obtain /dev/dm-0, even if you
specified /dev/mapper/mpatha.
My problem is in SuSE, the devtmpfs is mounted on /dev by default, seems
used by udev. And df reports devtmpfs on /dev/dm-0, instead of ext4.

What version of xfstests are you using? Do you have a
"README.device-mapper" file in the base directory? If not, upgrade
to the latest version and retry.

$ gl -n 1 -p 0a81886
commit 0a818862bb74932e15971ec8bedb55765ec3a3f6
Author: Christoph Hellwig <hch@xxxxxx>
Date:   Wed May 4 16:28:32 2011 +0200

     xfstests: support post-udev device mapper nodes

     Because of udevs complaining device mapper now creates /dev/dm-N as the real
     device nodes, and just symlinks the /dev/mapper/ names to it.  This would be
     easy if everything used the /dev/mapper clear names, but most system utilities
     translate them back to the /dev/mapper/ names and thus confuse various test
     cases.  Add support to _is_block_dev to read symlinks, and add documentation
     on how to run xfstests on device mapper volumes.

     Signed-off-by: Christoph Hellwig <hch@xxxxxx>
     Reviewed-by: Alex Elder <aelder@xxxxxxx>

Cheers,

Dave.


Recent "realpath" changes also went in:

b03c662399956609934ff063e9064e15dc7459ac xfstests: fix to build src/realpath and the correct the existence of target devices
d5ea873fcbf00b841f0511a26fb341364a5c6425 xfstests: resolve symlinked devices to real paths

so either of those could have broken and/or fixed it for you :)

Yup, those are almost certainly the patches that broke device mapper
support. There' aren't changes to common.rc, so I didn't notice them.
They basically override the fix that Christoph made to support
/dev/mapper links properly.

I'd suggest a revert is in order, the two patches above were part
of Rich's hovering of old, unreviewed patches. This problem was
already fixed in a different way by Christoph, so adding these
patches was wrong.

Fine with me ...

Ryan, can you test w/o those, and if it works -

Rich, can you revert those please?

Sure, I will wait to hear from Ryan first.


-Eric

Cheers,

Dave.


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



--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux