* umount and findmnt commands not working with btrfs labels ...
@ 2013-05-06 22:28 George Mitchell
2013-05-07 9:48 ` Karel Zak
0 siblings, 1 reply; 14+ messages in thread
From: George Mitchell @ 2013-05-06 22:28 UTC (permalink / raw)
To: util-linux
Hello all, I am having problems with some sort of bug in the umount
command that causes it not to process hyphenated labels on btrfs
volumes. Here is the scenario:
[root@localhost ghmitch]# mount -l
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs
(rw,nosuid,size=2065704k,nr_inodes=194082,mode=755)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
/dev/sde1 on / type btrfs (rw,relatime,space_cache) [MAGEIA3BTR]
/dev/sdc2 on /usr type btrfs (rw,relatime,space_cache) [MAGEIA3BTR-USR]
securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime,mode=755)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
none on /tmp type tmpfs (rw,relatime)
/dev/sdb5 on /boot type btrfs (rw,relatime,space_cache) [MAGEIA3BTR-BOOT]
/dev/sde3 on /home type btrfs (rw,relatime,space_cache) [HOME]
/dev/sde4 on /common type btrfs (rw,relatime,space_cache) [COMMON]
[root@localhost ghmitch]# umount LABEL=MAGEIA3BTR-BOOT
umount: LABEL=MAGEIA3BTR-BOOT: not found
[root@localhost ghmitch]# umount `mount -l | egrep "\[MAGEIA3BTR-BOOT\]"
| cut -f1 -d" "`
[root@localhost ghmitch]# mount -l
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs
(rw,nosuid,size=2065704k,nr_inodes=194082,mode=755)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
/dev/sde1 on / type btrfs (rw,relatime,space_cache) [MAGEIA3BTR]
/dev/sdc2 on /usr type btrfs (rw,relatime,space_cache) [MAGEIA3BTR-USR]
securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime,mode=755)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
none on /tmp type tmpfs (rw,relatime)
/dev/sde3 on /home type btrfs (rw,relatime,space_cache) [HOME]
/dev/sde4 on /common type btrfs (rw,relatime,space_cache) [COMMON]
[root@localhost ghmitch]# mount LABEL=MAGEIA3BTR-BOOT
[root@localhost ghmitch]# mount -l
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs
(rw,nosuid,size=2065704k,nr_inodes=194082,mode=755)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
/dev/sde1 on / type btrfs (rw,relatime,space_cache) [MAGEIA3BTR]
/dev/sdc2 on /usr type btrfs (rw,relatime,space_cache) [MAGEIA3BTR-USR]
securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup
(rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup
(rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/devices type cgroup
(rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup
(rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup
(rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup
(rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime,mode=755)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
none on /tmp type tmpfs (rw,relatime)
/dev/sde3 on /home type btrfs (rw,relatime,space_cache) [HOME]
/dev/sde4 on /common type btrfs (rw,relatime,space_cache) [COMMON]
/dev/sdb5 on /boot type btrfs (rw,relatime,space_cache) [MAGEIA3BTR-BOOT]
[root@localhost ghmitch]#
As you can see, mount has no problem with hyphenated btrfs labels. And
when I use a workaround script to unmount the filesystem via a label,
that works fine. But the umount LABEL=XXX-00 format fails every time.
This seems almost like a regression of sorts since I remember long ago
having EXACTLY the same problem with umount and ext4 partitions. The
findmnt command also has problems with btrfs labels in general. Every
instance of `findmnt LABEL=XXX` I have tried on btrfs volumes fails.
Example below:
[root@localhost ghmitch]# findmnt LABEL=MAGEIA3BTR [root@localhost
ghmitch]# findmnt `mount -l | egrep "\[MAGEIA3BTR\]" | cut -f1 -d" "`
TARGET SOURCE FSTYPE OPTIONS / /dev/sde1 btrfs rw,relatime,space_cache
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-06 22:28 umount and findmnt commands not working with btrfs labels George Mitchell
@ 2013-05-07 9:48 ` Karel Zak
2013-05-07 14:10 ` George Mitchell
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Karel Zak @ 2013-05-07 9:48 UTC (permalink / raw)
To: George Mitchell; +Cc: util-linux
Hi George,
On Mon, May 06, 2013 at 03:28:53PM -0700, George Mitchell wrote:
> [root@localhost ghmitch]# umount LABEL=MAGEIA3BTR-BOOT
>
> umount: LABEL=MAGEIA3BTR-BOOT: not found
umount --version ?
It works for me (tested with util-linux 2.22 and 2.23):
# mkfs.btrfs -L MAGEIA3BTR /dev/sdb1
# mkfs.btrfs -L MAGEIA3BTR-FOO /dev/sdb2
# mount LABEL=MAGEIA3BTR /mnt/test
# mount LABEL=MAGEIA3BTR-FOO /mnt/test
# findmnt LABEL=MAGEIA3BTR
TARGET SOURCE FSTYPE OPTIONS
/mnt/test /dev/sdb1 btrfs rw,relatime,ssd,space_cache
# findmnt LABEL=MAGEIA3BTR-FOO
TARGET SOURCE FSTYPE OPTIONS
/mnt/test2 /dev/sdb2 btrfs rw,relatime,ssd,space_cache
# umount LABEL=MAGEIA3BTR
# umount LABEL=MAGEIA3BTR-FOO
# lsblk --fs /dev/sdb
NAME FSTYPE LABEL UUID MOUNTPOINT
sdb
├─sdb1 btrfs MAGEIA3BTR 6dcc3293-ce27-474f-ab31-dd7a8e5bb2da
└─sdb2 btrfs MAGEIA3BTR-FOO f3bb2d57-8b46-40a0-ae76-50d78268d6d9
It would be nice to have a simple reproducible scenario rather than a
lot of mount -l outputs and some egrep tricks :-)
You can also try
LIBMOUNT_DEBUG=0xffff umount LABEL=MAGEIA3BTR-BOOT
to see more details.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-07 9:48 ` Karel Zak
@ 2013-05-07 14:10 ` George Mitchell
2013-05-07 14:48 ` George Mitchell
2013-05-07 15:10 ` George Mitchell
2 siblings, 0 replies; 14+ messages in thread
From: George Mitchell @ 2013-05-07 14:10 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
On 05/07/2013 02:48 AM, Karel Zak wrote:
> Hi George,
>
> On Mon, May 06, 2013 at 03:28:53PM -0700, George Mitchell wrote:
>> [root@localhost ghmitch]# umount LABEL=MAGEIA3BTR-BOOT
>>
>> umount: LABEL=MAGEIA3BTR-BOOT: not found
> umount --version ?
>
> It works for me (tested with util-linux 2.22 and 2.23):
>
> # mkfs.btrfs -L MAGEIA3BTR /dev/sdb1
> # mkfs.btrfs -L MAGEIA3BTR-FOO /dev/sdb2
>
> # mount LABEL=MAGEIA3BTR /mnt/test
> # mount LABEL=MAGEIA3BTR-FOO /mnt/test
>
> # findmnt LABEL=MAGEIA3BTR
> TARGET SOURCE FSTYPE OPTIONS
> /mnt/test /dev/sdb1 btrfs rw,relatime,ssd,space_cache
>
> # findmnt LABEL=MAGEIA3BTR-FOO
> TARGET SOURCE FSTYPE OPTIONS
> /mnt/test2 /dev/sdb2 btrfs rw,relatime,ssd,space_cache
>
> # umount LABEL=MAGEIA3BTR
> # umount LABEL=MAGEIA3BTR-FOO
>
> # lsblk --fs /dev/sdb
> NAME FSTYPE LABEL UUID MOUNTPOINT
> sdb
> ├─sdb1 btrfs MAGEIA3BTR 6dcc3293-ce27-474f-ab31-dd7a8e5bb2da
> └─sdb2 btrfs MAGEIA3BTR-FOO f3bb2d57-8b46-40a0-ae76-50d78268d6d9
>
>
> It would be nice to have a simple reproducible scenario rather than a
> lot of mount -l outputs and some egrep tricks :-)
>
> You can also try
>
> LIBMOUNT_DEBUG=0xffff umount LABEL=MAGEIA3BTR-BOOT
>
> to see more details.
>
> Karel
>
Thanks, and sorry for including all the garbage. I just wanted to make
sure I didn't leave anything out. The version I have here is 2.22.2. I
retested it using the DEBUG statement and it then worked and findmnt now
works OK as well, so I don't know what was going on. Something seems to
have gotten cleaned up somewhere. Tonight I will retest it on my other
system that I use for maintainance on the USR partition since it would
probably be unwise to fiddle with the USR partition with the system
running. At that point I will repost letting you know what I find. -
George
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-07 9:48 ` Karel Zak
2013-05-07 14:10 ` George Mitchell
@ 2013-05-07 14:48 ` George Mitchell
2013-05-09 9:42 ` Karel Zak
2013-05-07 15:10 ` George Mitchell
2 siblings, 1 reply; 14+ messages in thread
From: George Mitchell @ 2013-05-07 14:48 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
On 05/07/2013 02:48 AM, Karel Zak wrote:
> Hi George,
>
> On Mon, May 06, 2013 at 03:28:53PM -0700, George Mitchell wrote:
>> [root@localhost ghmitch]# umount LABEL=MAGEIA3BTR-BOOT
>>
>> umount: LABEL=MAGEIA3BTR-BOOT: not found
> umount --version ?
>
> It works for me (tested with util-linux 2.22 and 2.23):
>
> # mkfs.btrfs -L MAGEIA3BTR /dev/sdb1
> # mkfs.btrfs -L MAGEIA3BTR-FOO /dev/sdb2
>
> # mount LABEL=MAGEIA3BTR /mnt/test
> # mount LABEL=MAGEIA3BTR-FOO /mnt/test
>
> # findmnt LABEL=MAGEIA3BTR
> TARGET SOURCE FSTYPE OPTIONS
> /mnt/test /dev/sdb1 btrfs rw,relatime,ssd,space_cache
>
> # findmnt LABEL=MAGEIA3BTR-FOO
> TARGET SOURCE FSTYPE OPTIONS
> /mnt/test2 /dev/sdb2 btrfs rw,relatime,ssd,space_cache
>
> # umount LABEL=MAGEIA3BTR
> # umount LABEL=MAGEIA3BTR-FOO
>
> # lsblk --fs /dev/sdb
> NAME FSTYPE LABEL UUID MOUNTPOINT
> sdb
> ├─sdb1 btrfs MAGEIA3BTR 6dcc3293-ce27-474f-ab31-dd7a8e5bb2da
> └─sdb2 btrfs MAGEIA3BTR-FOO f3bb2d57-8b46-40a0-ae76-50d78268d6d9
>
>
> It would be nice to have a simple reproducible scenario rather than a
> lot of mount -l outputs and some egrep tricks :-)
>
> You can also try
>
> LIBMOUNT_DEBUG=0xffff umount LABEL=MAGEIA3BTR-BOOT
>
> to see more details.
>
> Karel
>
At this point findmnt works on MAGEIA3BTR-BOOT on which I previously
executed the umount with the debug prefix. findmnt still does NOT work
with MAGEIA3BTR (the root partition) or MAGEIA3BTR-USR (the usr
partition). Since I am not able to unmount either of these on a running
system with the debug statement, I have no way of knowing whether that
would fix the problem. Is there a different debug statement I can use
with findmnt? What I also don't know at this point is whether this is
going to be a permanent 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 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.
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
libmount: debug mask set to 0xffff.
4859: libmount: TAB: [0x97a6878]: alloc
4859: libmount: TAB: [0x97a6878]: /proc/self/mountinfo: start
parsing [entries=0, filter=not]
4859: libmount: TAB: trying to guess table type
4859: libmount: TAB: [0x97a6878]: add entry: proc /proc
4859: libmount: TAB: TID for /proc/self/mountinfo is 4859
4859: libmount: TAB: [0x97a6878]: add entry: sysfs /sys
4859: libmount: TAB: [0x97a6878]: add entry: devtmpfs /dev
4859: libmount: TAB: [0x97a6878]: add entry: devpts /dev/pts
4859: libmount: TAB: [0x97a6878]: add entry: tmpfs /dev/shm
4859: libmount: TAB: [0x97a6878]: add entry: tmpfs /run
4859: libmount: TAB: [0x97a6878]: add entry: /dev/sde1 /
4859: libmount: TAB: [0x97a6878]: add entry: /dev/sdc2 /usr
4859: libmount: TAB: [0x97a6878]: add entry: securityfs
/sys/kernel/security
4859: libmount: TAB: [0x97a6878]: add entry: tmpfs /sys/fs/cgroup
4859: libmount: TAB: [0x97a6878]: add entry: cgroup
/sys/fs/cgroup/systemd
4859: libmount: TAB: [0x97a6878]: add entry: cgroup
/sys/fs/cgroup/cpuset
4859: libmount: TAB: [0x97a6878]: add entry: cgroup
/sys/fs/cgroup/cpu,cpuacct
4859: libmount: TAB: [0x97a6878]: add entry: cgroup
/sys/fs/cgroup/devices
4859: libmount: TAB: [0x97a6878]: add entry: cgroup
/sys/fs/cgroup/freezer
4859: libmount: TAB: [0x97a6878]: add entry: cgroup
/sys/fs/cgroup/net_cls
4859: libmount: TAB: [0x97a6878]: add entry: cgroup
/sys/fs/cgroup/blkio
4859: libmount: TAB: [0x97a6878]: add entry: systemd-1
/proc/sys/fs/binfmt_misc
4859: libmount: TAB: [0x97a6878]: add entry: mqueue /dev/mqueue
4859: libmount: TAB: [0x97a6878]: add entry: hugetlbfs /dev/hugepages
4859: libmount: TAB: [0x97a6878]: add entry: debugfs /sys/kernel/debug
4859: libmount: TAB: [0x97a6878]: add entry: fusectl
/sys/fs/fuse/connections
4859: libmount: TAB: [0x97a6878]: add entry: none /tmp
4859: libmount: TAB: [0x97a6878]: add entry: /dev/sde3 /home
4859: libmount: TAB: [0x97a6878]: add entry: /dev/sde4 /common
4859: libmount: TAB: [0x97a6878]: add entry: /dev/sdb5 /boot
4859: libmount: TAB: [0x97a6878]: /proc/self/mountinfo: stop
parsing (26 entries)
4859: libmount: CACHE: [0x97a68a0]: alloc
4859: libmount: TAB: [0x97a6878]: lookup next fs
4859: libmount: CACHE: [0x97a68a0]: add entry [ 1] (tag): /dev/sdb5:
LABEL
4859: libmount: CACHE: [0x97a68a0]: add entry [ 2] (path): /dev/sde1:
/dev/sde1
4859: libmount: CACHE: [0x97a68a0]: add entry [ 3] (path): /dev/sdc2:
/dev/sdc2
4859: libmount: CACHE: [0x97a68a0]: add entry [ 4] (path): /dev/sde3:
/dev/sde3
4859: libmount: CACHE: [0x97a68a0]: add entry [ 5] (path): /dev/sde4:
/dev/sde4
4859: libmount: TAB: [0x97a6878]: lookup next fs
TARGET SOURCE FSTYPE OPTIONS
/boot /dev/sdb5 btrfs rw,relatime,space_cache
4859: libmount: TAB: [0x97a6878]: reset
4859: libmount: TAB: [0x97a6878]: free
4859: libmount: CACHE: [0x97a68a0]: free
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.
[root@localhost ghmitch]# LIBMOUNT_DEBUG=0xffff findmnt LABEL=MAGEIA3BTR
libmount: debug mask set to 0xffff.
4814: libmount: TAB: [0x861c878]: alloc
4814: libmount: TAB: [0x861c878]: /proc/self/mountinfo: start
parsing [entries=0, filter=not]
4814: libmount: TAB: trying to guess table type
4814: libmount: TAB: [0x861c878]: add entry: proc /proc
4814: libmount: TAB: TID for /proc/self/mountinfo is 4814
4814: libmount: TAB: [0x861c878]: add entry: sysfs /sys
4814: libmount: TAB: [0x861c878]: add entry: devtmpfs /dev
4814: libmount: TAB: [0x861c878]: add entry: devpts /dev/pts
4814: libmount: TAB: [0x861c878]: add entry: tmpfs /dev/shm
4814: libmount: TAB: [0x861c878]: add entry: tmpfs /run
4814: libmount: TAB: [0x861c878]: add entry: /dev/sde1 /
4814: libmount: TAB: [0x861c878]: add entry: /dev/sdc2 /usr
4814: libmount: TAB: [0x861c878]: add entry: securityfs
/sys/kernel/security
4814: libmount: TAB: [0x861c878]: add entry: tmpfs /sys/fs/cgroup
4814: libmount: TAB: [0x861c878]: add entry: cgroup
/sys/fs/cgroup/systemd
4814: libmount: TAB: [0x861c878]: add entry: cgroup
/sys/fs/cgroup/cpuset
4814: libmount: TAB: [0x861c878]: add entry: cgroup
/sys/fs/cgroup/cpu,cpuacct
4814: libmount: TAB: [0x861c878]: add entry: cgroup
/sys/fs/cgroup/devices
4814: libmount: TAB: [0x861c878]: add entry: cgroup
/sys/fs/cgroup/freezer
4814: libmount: TAB: [0x861c878]: add entry: cgroup
/sys/fs/cgroup/net_cls
4814: libmount: TAB: [0x861c878]: add entry: cgroup
/sys/fs/cgroup/blkio
4814: libmount: TAB: [0x861c878]: add entry: systemd-1
/proc/sys/fs/binfmt_misc
4814: libmount: TAB: [0x861c878]: add entry: mqueue /dev/mqueue
4814: libmount: TAB: [0x861c878]: add entry: hugetlbfs /dev/hugepages
4814: libmount: TAB: [0x861c878]: add entry: debugfs /sys/kernel/debug
4814: libmount: TAB: [0x861c878]: add entry: fusectl
/sys/fs/fuse/connections
4814: libmount: TAB: [0x861c878]: add entry: none /tmp
4814: libmount: TAB: [0x861c878]: add entry: /dev/sde3 /home
4814: libmount: TAB: [0x861c878]: add entry: /dev/sde4 /common
4814: libmount: TAB: [0x861c878]: add entry: /dev/sdb5 /boot
4814: libmount: TAB: [0x861c878]: /proc/self/mountinfo: stop
parsing (26 entries)
4814: libmount: CACHE: [0x861c8a0]: alloc
4814: libmount: TAB: [0x861c878]: lookup next fs
4814: libmount: CACHE: [0x861c8a0]: add entry [ 1] (tag): /dev/sdd1:
LABEL
4814: libmount: CACHE: [0x861c8a0]: add entry [ 2] (path): /dev/sde1:
/dev/sde1
4814: libmount: CACHE: [0x861c8a0]: add entry [ 3] (path): /dev/sdc2:
/dev/sdc2
4814: libmount: CACHE: [0x861c8a0]: add entry [ 4] (path): /dev/sde3:
/dev/sde3
4814: libmount: CACHE: [0x861c8a0]: add entry [ 5] (path): /dev/sde4:
/dev/sde4
4814: libmount: CACHE: [0x861c8a0]: add entry [ 6] (path): /dev/sdb5:
/dev/sdb5
4814: libmount: TAB: [0x861c878]: reset
4814: libmount: TAB: [0x861c878]: free
4814: libmount: CACHE: [0x861c8a0]: free
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:
/dev/sda5: LABEL="MAGEIA3BTR-BOOT"
UUID="63f13151-dd34-45e1-b40d-7ed7d0d0ec4a"
UUID_SUB="978f5c02-5e11-4df4-8f72-4ff6d09e58ff" TYPE="btrfs"
/dev/sda6: LABEL="MAGEIA3X64-BOOT"
UUID="9b4a4323-2e8a-46bb-8773-a37a6d9e663d" TYPE="ext4"
/dev/sda7: UUID="aac18bf5-9d32-4b4d-99ae-31bd19b23f10" TYPE="ext4"
/dev/sdb5: LABEL="MAGEIA3BTR-BOOT"
UUID="63f13151-dd34-45e1-b40d-7ed7d0d0ec4a"
UUID_SUB="0587a676-8bad-4d61-a8af-0e262d997ba7" TYPE="btrfs"
/dev/sdb6: UUID="8b3905fa-9431-4ca2-b88d-2f3382790e10" TYPE="ext4"
/dev/sdc1: LABEL="MAGEIA3BTR"
UUID="2ead7897-2203-4846-9fef-22aac314634d"
UUID_SUB="9f1a5494-eb9b-48d1-8169-2e10682f0ed7" TYPE="btrfs"
/dev/sdc2: LABEL="MAGEIA3BTR-USR"
UUID="d2bd46ff-c25d-4302-b708-76e81dc09977"
UUID_SUB="fb11bf5c-5fcc-4f43-a8b5-502f7f3b80b2" TYPE="btrfs"
/dev/sdc3: LABEL="HOME" UUID="f5bb2e04-2a27-4d8c-9b59-a637f3a51e9a"
UUID_SUB="d730117f-5293-4d73-b1e1-213550bb58aa" TYPE="btrfs"
/dev/sdc4: LABEL="COMMON" UUID="4b0983d7-8d85-463d-85c1-c20aa3b4fa3b"
UUID_SUB="2fed487e-c68a-4688-8ab7-526751d50e62" TYPE="btrfs"
/dev/sdd1: LABEL="MAGEIA3BTR"
UUID="2ead7897-2203-4846-9fef-22aac314634d"
UUID_SUB="831dcba5-ace6-44a4-8a23-94ac38f397f6" TYPE="btrfs"
/dev/sdd2: LABEL="MAGEIA3BTR-USR"
UUID="d2bd46ff-c25d-4302-b708-76e81dc09977"
UUID_SUB="69befc01-5166-466a-b16f-e360a1acd591" TYPE="btrfs"
/dev/sdd3: LABEL="HOME" UUID="f5bb2e04-2a27-4d8c-9b59-a637f3a51e9a"
UUID_SUB="54ff9459-5487-42f8-a8f8-4d6eaa0cd6ef" TYPE="btrfs"
/dev/sdd4: LABEL="COMMON" UUID="4b0983d7-8d85-463d-85c1-c20aa3b4fa3b"
UUID_SUB="91b80d1e-1a9c-4a1a-9f5f-e396ea205085" TYPE="btrfs"
/dev/sde1: LABEL="MAGEIA3BTR"
UUID="2ead7897-2203-4846-9fef-22aac314634d"
UUID_SUB="1c815643-ceb5-4cc8-be6b-35e3d4262dd1" TYPE="btrfs"
/dev/sde2: LABEL="MAGEIA3X64"
UUID="6c63a6ad-def8-47d5-95cb-6fba898b1578" TYPE="ext4"
/dev/sde3: LABEL="HOME" UUID="f5bb2e04-2a27-4d8c-9b59-a637f3a51e9a"
UUID_SUB="8e3a2572-7ab7-4aac-9c01-497a06541786" TYPE="btrfs"
/dev/sde4: LABEL="COMMON" UUID="4b0983d7-8d85-463d-85c1-c20aa3b4fa3b"
UUID_SUB="8e4a1292-980a-4815-9d1f-c43c312bfeb8" TYPE="btrfs"
/dev/sdf2: LABEL="MAGEIA3BTR-USR"
UUID="d2bd46ff-c25d-4302-b708-76e81dc09977"
UUID_SUB="3cc25d5d-534a-4ae5-a5f8-20648cb8c33c" TYPE="btrfs"
/dev/sdf3: LABEL="HOME" UUID="f5bb2e04-2a27-4d8c-9b59-a637f3a51e9a"
UUID_SUB="9bea9ca7-73e9-4290-bc8b-b94771c3e362" TYPE="btrfs"
/dev/sdf4: LABEL="COMMON" UUID="4b0983d7-8d85-463d-85c1-c20aa3b4fa3b"
UUID_SUB="1e459a35-ed8d-4021-b6ea-161bda96305a" TYPE="btrfs"
/dev/sdg2: LABEL="MAGEIA3BTR-USR"
UUID="d2bd46ff-c25d-4302-b708-76e81dc09977"
UUID_SUB="6bc4b144-c90c-4df5-9008-6a98934b55e4" TYPE="btrfs"
/dev/sdg3: LABEL="HOME" UUID="f5bb2e04-2a27-4d8c-9b59-a637f3a51e9a"
UUID_SUB="206f43d8-f51a-4080-b674-26de2dea5ce5" TYPE="btrfs"
/dev/sdg4: LABEL="COMMON" UUID="4b0983d7-8d85-463d-85c1-c20aa3b4fa3b"
UUID_SUB="92bfb4cb-9f4b-4277-ad5e-fe6cf34d368f" TYPE="btrfs"
/dev/sdh1: LABEL="HOME_MIRROR"
UUID="725f431e-0d70-49d5-b0d6-ca2805385dc9" TYPE="jfs"
PARTUUID="850816a4-2cb1-40f2-ac8b-23fedda3f40f"
/dev/sdi: LABEL="BACKUP" UUID="534d18b0-fc56-42e6-bfeb-c63b0f0bdc07"
UUID_SUB="8467e093-5f14-4124-98e5-fb80303ec851" TYPE="btrfs"
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-07 9:48 ` Karel Zak
2013-05-07 14:10 ` George Mitchell
2013-05-07 14:48 ` George Mitchell
@ 2013-05-07 15:10 ` George Mitchell
2 siblings, 0 replies; 14+ messages in thread
From: George Mitchell @ 2013-05-07 15:10 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
On 05/07/2013 02:48 AM, Karel Zak wrote:
> Hi George,
>
> On Mon, May 06, 2013 at 03:28:53PM -0700, George Mitchell wrote:
>> [root@localhost ghmitch]# umount LABEL=MAGEIA3BTR-BOOT
>>
>> umount: LABEL=MAGEIA3BTR-BOOT: not found
> umount --version ?
>
> It works for me (tested with util-linux 2.22 and 2.23):
>
> # mkfs.btrfs -L MAGEIA3BTR /dev/sdb1
> # mkfs.btrfs -L MAGEIA3BTR-FOO /dev/sdb2
>
> # mount LABEL=MAGEIA3BTR /mnt/test
> # mount LABEL=MAGEIA3BTR-FOO /mnt/test
>
> # findmnt LABEL=MAGEIA3BTR
> TARGET SOURCE FSTYPE OPTIONS
> /mnt/test /dev/sdb1 btrfs rw,relatime,ssd,space_cache
>
> # findmnt LABEL=MAGEIA3BTR-FOO
> TARGET SOURCE FSTYPE OPTIONS
> /mnt/test2 /dev/sdb2 btrfs rw,relatime,ssd,space_cache
>
> # umount LABEL=MAGEIA3BTR
> # umount LABEL=MAGEIA3BTR-FOO
>
> # lsblk --fs /dev/sdb
> NAME FSTYPE LABEL UUID MOUNTPOINT
> sdb
> ├─sdb1 btrfs MAGEIA3BTR 6dcc3293-ce27-474f-ab31-dd7a8e5bb2da
> └─sdb2 btrfs MAGEIA3BTR-FOO f3bb2d57-8b46-40a0-ae76-50d78268d6d9
>
>
> It would be nice to have a simple reproducible scenario rather than a
> lot of mount -l outputs and some egrep tricks :-)
>
> You can also try
>
> LIBMOUNT_DEBUG=0xffff umount LABEL=MAGEIA3BTR-BOOT
>
> to see more details.
>
> Karel
>
Just to further illustrate the complexity here:
[root@localhost ghmitch]# blkid | egrep COMMON
/dev/sdc4: LABEL="COMMON" UUID="4b0983d7-8d85-463d-85c1-c20aa3b4fa3b"
UUID_SUB="2fed487e-c68a-4688-8ab7-526751d50e62" TYPE="btrfs"
/dev/sdd4: LABEL="COMMON" UUID="4b0983d7-8d85-463d-85c1-c20aa3b4fa3b"
UUID_SUB="91b80d1e-1a9c-4a1a-9f5f-e396ea205085" TYPE="btrfs"
/dev/sde4: LABEL="COMMON" UUID="4b0983d7-8d85-463d-85c1-c20aa3b4fa3b"
UUID_SUB="8e4a1292-980a-4815-9d1f-c43c312bfeb8" TYPE="btrfs"
/dev/sdf4: LABEL="COMMON" UUID="4b0983d7-8d85-463d-85c1-c20aa3b4fa3b"
UUID_SUB="1e459a35-ed8d-4021-b6ea-161bda96305a" TYPE="btrfs"
/dev/sdg4: LABEL="COMMON" UUID="4b0983d7-8d85-463d-85c1-c20aa3b4fa3b"
UUID_SUB="92bfb4cb-9f4b-4277-ad5e-fe6cf34d368f" TYPE="btrfs"
[root@localhost ghmitch]# mount -l | egrep COMMON
/dev/sde4 on /common type btrfs (rw,relatime,space_cache) [COMMON]
if findmnt OR umount simply search for an association between the LABEL
and the DEVICE, how do they come up with the correct mount point when
only ONE of the devices involved will serve as the mount point?
Hopefully that question better describes the problem. - George
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-07 14:48 ` George Mitchell
@ 2013-05-09 9:42 ` Karel Zak
2013-05-09 14:06 ` George Mitchell
2013-05-09 16:01 ` George Mitchell
0 siblings, 2 replies; 14+ messages in thread
From: Karel Zak @ 2013-05-09 9:42 UTC (permalink / raw)
To: George Mitchell; +Cc: util-linux
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@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-09 9:42 ` Karel Zak
@ 2013-05-09 14:06 ` George Mitchell
2013-05-09 18:53 ` Karel Zak
2013-05-09 16:01 ` George Mitchell
1 sibling, 1 reply; 14+ messages in thread
From: George Mitchell @ 2013-05-09 14:06 UTC (permalink / raw)
To: Karel Zak, util-linux
So what I think I hear you saying on this issue is that though I can
easily turn a label into a mount point with my little grep trick, umount
is unable to do that so that in my scripts I will always have to use
this kluge for things to work correctly? And that of course the same
would hold true with findmnt?
On 05/09/2013 02:42 AM, Karel Zak wrote:
> 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
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-09 9:42 ` Karel Zak
2013-05-09 14:06 ` George Mitchell
@ 2013-05-09 16:01 ` George Mitchell
2013-05-09 16:59 ` Helmut Hullen
` (2 more replies)
1 sibling, 3 replies; 14+ messages in thread
From: George Mitchell @ 2013-05-09 16:01 UTC (permalink / raw)
To: Karel Zak, util-linux
On 05/09/2013 02:42 AM, Karel Zak wrote:
> 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, Your answer left me really frustrated, but after rethinking the
whole thing, I am left wondering if this whole issue, including the
broader issue of what should appear on the mount table in the first
place, would be better addressed by the btrfs group simply abstracting
the mount point like software raid has always done and handling all the
details internally within btrfs. I already have seen applications that
didn't understand btrfs partitions were in use and bad things could
result from that. It would be nice if btrfs would just lock all of
these partitions out and represent them collectively to the broader
system as /dev/mntX or whatever. That would surely greatly simplify
things for everybody. I am going broach that idea on the btrfs list.
Thanks so much for taking the time to discuss this with me. It is much
appreciated even though at the time I was not so happy with some of your
answers. - George
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-09 16:01 ` George Mitchell
@ 2013-05-09 16:59 ` Helmut Hullen
2013-05-09 19:07 ` Karel Zak
2013-05-09 19:54 ` Roger Leigh
2 siblings, 0 replies; 14+ messages in thread
From: Helmut Hullen @ 2013-05-09 16:59 UTC (permalink / raw)
To: util-linux
Hallo, George,
Du meintest am 09.05.13:
>> 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.
[...]
> It would be nice if btrfs would just lock all of these partitions out
> and represent them collectively to the broader system as /dev/mntX or
> whatever.
Perhaps you shouldn't use only "blkid" - sometimes I've seen strange
answers (or no answer). I haven't yet found the system behind this
behaviour.
file -s /dev/sdd1
(p.e.) is more reliable.
But for mounting and unmounting I haven't seen any problem:
mount LABEL=FOO /path/to/mountpoint
umount LABEL=FOO
has always worked as expected; for existing devices and mountpoints and
also for nonexisting devices and mountpoints.
By the way: my system doesn't use "udev"; working/addressing with LABEL
works fine also without "udev".
And by another way:
blkid
tells every btrfs disk/partition which is part of the btrfs cluster (in
my installations: all 3 disks) - they have the same UUID but different
UUID_SUBs. No real problem.
Viele Gruesse!
Helmut
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-09 14:06 ` George Mitchell
@ 2013-05-09 18:53 ` Karel Zak
0 siblings, 0 replies; 14+ messages in thread
From: Karel Zak @ 2013-05-09 18:53 UTC (permalink / raw)
To: George Mitchell; +Cc: util-linux
On Thu, May 09, 2013 at 07:06:28AM -0700, George Mitchell wrote:
> So what I think I hear you saying on this issue is that though I can easily
> turn a label into a mount point with my little grep trick, umount is unable
> to do that so that in my scripts I will always have to use this kluge for
> things to work correctly? And that of course the same would hold true with
> findmnt?
Yes, this is not btrfs issue only, this is a generic problem:
mount LABEL=foo /A
mount LABEL=foo /B
umount LABEL=foo
.. do you want to umount /A or /B ?
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-09 16:01 ` George Mitchell
2013-05-09 16:59 ` Helmut Hullen
@ 2013-05-09 19:07 ` Karel Zak
2013-05-09 19:54 ` Roger Leigh
2 siblings, 0 replies; 14+ messages in thread
From: Karel Zak @ 2013-05-09 19:07 UTC (permalink / raw)
To: George Mitchell; +Cc: util-linux
On Thu, May 09, 2013 at 09:01:49AM -0700, George Mitchell wrote:
> Karel, Your answer left me really frustrated, but after rethinking the
> whole thing, I am left wondering if this whole issue, including the broader
> issue of what should appear on the mount table in the first place, would be
> better addressed by the btrfs group simply abstracting the mount point like
> software raid has always done and handling all the details internally within
> btrfs. I already have seen applications that didn't understand btrfs
> partitions were in use and bad things could result from that. It would be
> nice if btrfs would just lock all of these partitions out and represent them
> collectively to the broader system as /dev/mntX or whatever. That would
Do you mean abstract (virtual) block device (like we have for
device-mapper, e.g /dev/dm0)? I think it's btrfs *feature* that there
is not any virtual block device :-)
> surely greatly simplify things for everybody. I am going broach that idea
> on the btrfs list.
Well, it depends, nothing is perfect. The things like /dev/dm0 have
some disadvantages (it's extra layer, extra support in userspace,
etc.)
Maybe possible solution would be to export more information about the
btrfs filesystem in /proc, for example add complete list of all used
(mapped) devices to /proc/self/mountinfo.
> Thanks so much for taking the time to discuss this with
> me. It is much appreciated even though at the time I was not so happy with
> some of your answers. - George
We will see more problems with btrfs, because it provides completely
new and different point of view where filesystem != device,
multi-root filesystems, raids, subvolumes, etc.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-09 16:01 ` George Mitchell
2013-05-09 16:59 ` Helmut Hullen
2013-05-09 19:07 ` Karel Zak
@ 2013-05-09 19:54 ` Roger Leigh
2013-05-10 0:15 ` George Mitchell
2013-05-10 8:28 ` Karel Zak
2 siblings, 2 replies; 14+ messages in thread
From: Roger Leigh @ 2013-05-09 19:54 UTC (permalink / raw)
To: George Mitchell; +Cc: util-linux
On Thu, May 09, 2013 at 09:01:49AM -0700, George Mitchell wrote:
> Karel, Your answer left me really frustrated, but after rethinking
> the whole thing, I am left wondering if this whole issue, including
> the broader issue of what should appear on the mount table in the
> first place, would be better addressed by the btrfs group simply
> abstracting the mount point like software raid has always done and
> handling all the details internally within btrfs. I already have
> seen applications that didn't understand btrfs partitions were in
> use and bad things could result from that. It would be nice if
> btrfs would just lock all of these partitions out and represent them
> collectively to the broader system as /dev/mntX or whatever. That
> would surely greatly simplify things for everybody. I am going
> broach that idea on the btrfs list.
If you do bring this up on the list, a related problem that breaks
a number of tools, and also boot-time fsck on Debian systems, is
that the device reported by stat(2) st_rdev is fictional and not
present in /dev. This is probably because every subvolume has a
different device ID. But it's not exposed to userspace.
If you want to get the device node to fsck from a read-only
mount, then you're stuck. And it also breaks other tools which
expect the device number to actually have real meaning. Btrfs is
AFAICT unique in this respect, and it's quite broken to behave in
this way.
If the filesystem could expose real devices to userspace, that
would IMO be a big improvement. Even if it's just a virtual
"proxy" for the filesystem.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-09 19:54 ` Roger Leigh
@ 2013-05-10 0:15 ` George Mitchell
2013-05-10 8:28 ` Karel Zak
1 sibling, 0 replies; 14+ messages in thread
From: George Mitchell @ 2013-05-10 0:15 UTC (permalink / raw)
To: util-linux
On 05/09/2013 12:54 PM, Roger Leigh wrote:
> If the filesystem could expose real devices to userspace, that would
> IMO be a big improvement. Even if it's just a virtual "proxy" for the
> filesystem. Regards, Roger
On 05/09/2013 12:07 PM, Karel Zak wrote:
>
> Do you mean abstract (virtual) block device (like we have for
> device-mapper, e.g /dev/dm0)? I think it's btrfs *feature* that there
> is not any virtual block device :)
To address both of these comments, let me say this. btrfs provides many
of the capabilities of traditional RAID, THAT is a FEATURE. btrfs
provides many of the capabilities of traditional LVM. THAT is a
FEATURE. IF btrfs would provide a virtual "hook" (yes Karel, an
abstract virtual block device, exactly!) that would be UNCHANGING, THAT
would be a FEATURE. The fact that it does not is NOT a feature, is
rather a shortcoming. It is like the used car salesman telling you that
the fact the car he is selling is missing the spare tire is a "feature"
(imagine all the gas you will save by not having to tow it around or
maintain it). FEATURES are about capabilities, not just lack of
complexity. Lack of complexity IS a feature IF it retains capability.
In the case of btrfs, if my mount point drive breaks in service and I
remove it, my mount point has just changed since the previous mount
point is no longer even part of the volume anymore. Those are the kind
of issues that irritate me to no end. All the partitions involved in a
btrfs volume are, in effect, "mounted" whether or not they appear on the
mount table, whenever the volume is mounted. But if I use a drive
partitioning tool, IT doesn't know they are mounted because it is
looking in the usual places. On the other hand if they were assigned a
virtual mount point all this would get taken care of. I have used
traditional RAID both software and hardware for years now. With
software RAID the virtual mount point is actually /dev/mdX. Its been
long enough since I last used software RAID that I had forgotten the
label format. In the case of LVM, which I have never used, you can
apparently make the label whatever you want it to be and can use them to
describe subvolumes as well. THAT WOULD BE A FEATURE! They carry the
format /dev/FOO/SUB1 or just /dev/FOO for example. But they describe
the whole volume and whether you add partitions or subtract partitions,
the device name remains virtually immutable. IMHO, a LOT of the problems
we are experiencing now with btrfs can in some way be traced back to
this arcane approach (my own opinion of course) of doing things without
reliable virtual mount points. In some ways trying to contain btrfs is
like trying to contain a jellyfish. But I have seen a lot of things
come and go over the years. I started out back in the mid 1980s doing
system administration on PDP 1170s running programmers workbench UNIX.
And the more things change, the more they stay the same. But eventually
I suppose it will work itself out. In the mean time we will all just
have to be creative.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: umount and findmnt commands not working with btrfs labels ...
2013-05-09 19:54 ` Roger Leigh
2013-05-10 0:15 ` George Mitchell
@ 2013-05-10 8:28 ` Karel Zak
1 sibling, 0 replies; 14+ messages in thread
From: Karel Zak @ 2013-05-10 8:28 UTC (permalink / raw)
To: Roger Leigh; +Cc: George Mitchell, util-linux
On Thu, May 09, 2013 at 08:54:14PM +0100, Roger Leigh wrote:
> On Thu, May 09, 2013 at 09:01:49AM -0700, George Mitchell wrote:
> > Karel, Your answer left me really frustrated, but after rethinking
> > the whole thing, I am left wondering if this whole issue, including
> > the broader issue of what should appear on the mount table in the
> > first place, would be better addressed by the btrfs group simply
> > abstracting the mount point like software raid has always done and
> > handling all the details internally within btrfs. I already have
> > seen applications that didn't understand btrfs partitions were in
> > use and bad things could result from that. It would be nice if
> > btrfs would just lock all of these partitions out and represent them
> > collectively to the broader system as /dev/mntX or whatever. That
> > would surely greatly simplify things for everybody. I am going
> > broach that idea on the btrfs list.
>
> If you do bring this up on the list, a related problem that breaks
> a number of tools, and also boot-time fsck on Debian systems, is
> that the device reported by stat(2) st_rdev is fictional and not
> present in /dev. This is probably because every subvolume has a
> different device ID. But it's not exposed to userspace.
Good point, this is the worst thing I don't like on btrfs.
https://bugzilla.redhat.com/show_bug.cgi?id=711881
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2013-05-10 8:28 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-05-06 22:28 umount and findmnt commands not working with btrfs labels George Mitchell
2013-05-07 9:48 ` Karel Zak
2013-05-07 14:10 ` George Mitchell
2013-05-07 14:48 ` George Mitchell
2013-05-09 9:42 ` Karel Zak
2013-05-09 14:06 ` George Mitchell
2013-05-09 18:53 ` Karel Zak
2013-05-09 16:01 ` George Mitchell
2013-05-09 16:59 ` Helmut Hullen
2013-05-09 19:07 ` Karel Zak
2013-05-09 19:54 ` Roger Leigh
2013-05-10 0:15 ` George Mitchell
2013-05-10 8:28 ` Karel Zak
2013-05-07 15:10 ` George Mitchell
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.