Bug 9975

I verified that umount is working on labels with dashes in the 32 bit Mageia 3 system.  The OTHER difference is that in the case of the 32 bit system the umount request involves unmounting a single ext4 partition.  In the case of the 64 bit Mageia 3 system that fails, the unmount request involves two btrfs partitions operating in RAID 1 mode.  I suspect that umount is having a problem with a label name with a dash ONLY in the case of btrfs multipartition mounts.  This suggests some sort of coding error within the umount binary itself, since I doubt that the 32 bit version source code differs from the 64 bit version source code.

As a workaround I am using the following until this gets fixed:


[root@localhost mnt]# umount `mount -l | egrep "\[MAGEIA3BTR-BOOT\]" | cut -d" " -f1`

Looks like a general util-linux issue I guess, but one we likely won't get a chance to look at until later. If at all possible co uld you come up with a bunch of commands to set things up in a way that demonstrates this (e.g. 1. assume two partitions /dev/sdb1 and /dev/sdb2 of type X; 2 mkbrtfs ... etc. etc.)?

That way we can test this much more easily (perhaps in a VM etc).

Thanks Colin, I understand you have a full plate right now and am in no hurry as I have a fully functional workaround for this one.  I will try to go through all the util-linux suite and test for other possibly related failures and post them against this bug report.  - George

If you're on IRC then the upstream util-linux maintainer is really approachable. Karel Zak or kzak on Freenode or https://plus.google.com/111319147897550904359/posts

He's always been helpful to me in the past.

Thanks.  At this point it looks like only umount and findmnt are affected.  Most util-linux commands are not fs related or do not support labels.  Of the ones that are blkid, findfs and wipefs look OK.  And fsck and mkfs are only frontends for external commands and thus are not affected.  - George

I know that umount and findmnt got a bit or rework recently upstream, so you never know it may be fixed by now anyway:

http://karelzak.blogspot.co.uk/2013/04/umount8-mount8-and-nsenter1.html

At this point I am subscribed to the util-linux list, so I will simply present the problem there and most likely someone on that list will be on top of the issue.  I will close this bug report as soon as a fix comes down.  Thanks,  George

I think I see what is going on here thanks to some help from Karel.  It appears that mount works fine because it simply grabs whatever /dev/sd.. it finds and mounts it and all works well.  But with umount, it grabs a /dev/sd.. and then goes to check the mount table and ... the /dev/sd.. on the mount table is a DIFFERENT device (part of the multipartition btrfs volume) and so umount responds that it can't find the LABEL.  It couldn't find the label because it couldn't find the device it was looking for which was part of the right volume but was NOT the mount point.  IF it HAPPENS by luck to select the right /dev/sd.. on the first pass the umount WILL succeed.  In the case of findmnt, the same logic is at work.  Karel tried to test this out and couldn't find the bug, but he was not using multipartition volumes.  I expect this to get VERY interesting when we stop using partitions altogether, which I am alreading doing with one 4TB volume.  Not partitioning simplifies the whole process especially in the case of huge hard drive sizes and it also makes "virtual partitioning" via subvolumes very attractive since they can be done dynamically on a running system and you can't do that safely with conventional partitioning.  - George

Colin,  What Karel seems to be telling me at this point is that this is NOT a bug and that he is basically NOT going to support umount by LABEL on multipartition btrfs volumes because technically only one of the partitions is mounted so there is really no way to umount the whole volume, or something such.  In other words, he considers it an enhancement request rather than a bug.  I find this mindset really exasperating because, while umount and findmnt are easily kluged around, other things are sitting out there that will likely face the same fate and will not be so easily kluged around.  And the effect will be to degrade the value of btrfs.  But I suppose that as much as I love the world of GPL software, there are some downsides that one just has to accept.  So, I am simply going to close this bug as resolved at this point because, if upstream won't deal with it, I don't think you should have to.  - George

Closing this bug as invalid per response from Karel Zak upstream util-linux maintainer.

Status: NEW => RESOLVED
Resolution: (none) => INVALID

FWIW, I think his interpretation is reasonable. It's a case that is kinda tricky to deal with generally (the whole argument could probably also apply to bind mounts within the same fs too).

Regardless of whether it's a bug or an enhancement, he's acknowledged that it's something that would need fixing even if the semantics are such that it's not *technically* a bug but an enhancement. btrfs is changing a lot of things generally and this is the kind of fallout at is expected IMO. No point in getting too worked up about it! :)

Thanks for reporting back tho'. Wish more bug reports were like this :) (although better outcomes would be nice!)