On Tue, May 07, 2013 at 07:48:40AM -0700, George Mitchell wrote:
> problem. Is there a different debug statement I can use with findmnt? What
LIBMOUNT_DEBUG= for libmount
LIBBLKID_DEBUG= for libblkid
We usually use /dev/disk/by-label and by-uuid/ to convert LABELs and
UUIDs to device names. These symlinks are maintained by udevd and
created according to result from
blkid -o udev -p <device>
the duplicate LABELs are ignored, there is only one LABEL of course.
> fix or whether I will need to redo this with each reboot? Also you did your
> testing with a simple one partition btrfs volume. My system involves up to
I had two independent partitions, each initialized by mkfs.btrfs.
> five partitions in a single RAID 1 volume. My boot volume is spread over
> two partitions. I am wondering if that could have something to do with it?
> In any case, here is what I come up with using the same debug prefix with
> findmnt.
Ah, do you mean btrfs raid? For example:
mkfs.btrfs --data raid1 --label FOO /dev/sdd1 /dev/sdd2
then the LABEL and UUID is really duplicate.
Anyway, the right way how to umount any filesystem is to specify the
filesystem by mountpoint, for example
umount /mnt
this is the way how Linux umount(2) syscall works, because everything
else is unreliable. Don't forget that you can mount the same filesystem
on more places and sometimes filesystem != device (e.g. btrfs), etc.
The umount-by-device is marked in the umount(8) man page as obsolete.
It seems I have to add a note about RAIDs too.
> Using findmnt on MAGEIA3BTR-BOOT produces the following. It appears to find
> the mount point and then print the result:
>
> [root@localhost ghmitch]# LIBMOUNT_DEBUG=0xffff findmnt
> LABEL=MAGEIA3BTR-BOOT
[...]
> However, when I do the same operation with MAGEIA3BTR, it DOES seem to find
> the mount point (4814: libmount: CACHE: [0x861c8a0]: add entry [ 1]
> (tag): /dev/sdd1: LABEL). The problem is, that is NOT the mount point. The
> mount point is /dev/sde1.
It seems that we need a note about duplicate LABELs to the man page ;-)
Note, for Linux RAID (mdadm(8)) we're able to detect that the
filesystem is within a raid member device (e.g. /dev/sda<N>) and the
device is reported as RAID member, the filesystem is ignored. The
filesystem is visible only on the final raid device (e.g /dev/md0).
It means that the duplicate filesystems (RAID1 members) are invisible.
I guess something like this is unnecessary for btrfs, because you can
mount arbitrary btrfs raid member (device) as btrfs kernel code is
able to find the next raid members and compose the final array.
> Here is my blkid which will give you an overview of the partitions involved.
> NOTE that with btrfs there are often multiple partitions with the same LABEL
> and UUID, but only ONE of those will be the mount point and that mount point
> can change at any time to one of the OTHER partitions sharing the same
> label. If umount OR findmnt happen to get the wrong mountpoint even with
> the right label, things are not going to work out:
So I don't see a bug. All what we need is to more explicitly explain
to users that conversion from <device|uuid|label> to <mountpoint> is
not reliable, because the same device could be mounted on more places
or the mountpoint could be connected to more devices.
> /dev/sda5: LABEL="MAGEIA3BTR-BOOT" UUID="63f13151-dd34-45e1-b40d-7ed7d0d0ec4a" UUID_SUB="978f5c02-5e11-4df4-8f72-4ff6d09e58ff" TYPE="btrfs"
> /dev/sdb5: LABEL="MAGEIA3BTR-BOOT" UUID="63f13151-dd34-45e1-b40d-7ed7d0d0ec4a" UUID_SUB="0587a676-8bad-4d61-a8af-0e262d997ba7" TYPE="btrfs"
Yes, I see.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
