Duncan, The problem affects btrfs volumes that span multiple drive. If
you are using btrfs on a single drive that works just fine. But in a
multidrive situation, sometimes it works (when umount guesses the right
device name) and sometimes it fails (when umount guesses the wrong
device name). Have fun! - George
On 05/20/2013 06:08 PM, Duncan wrote:
Chris Murphy posted on Sun, 19 May 2013 12:18:19 -0600 as excerpted:
On May 19, 2013, at 5:15 AM, Roman Mamedov <rm@xxxxxxxxxx> wrote:
From a user perspective btrfs subvolumes have a lot in common with just
regular directories aka folders, and nothing in common with
(block)devices.
"Describing them with virtual devices" does not seem to make a whole
lot of sense.
It's not possible to mount regular directories with other file systems.
Actually, it /is/ possible, using bind-mounts, etc. These even work at
the individual file level, and I use a few that way here, for mounting
usable device files over an otherwise nodev mounted filesystem (used for
a named/bind chroot, bind-mounted and then remounted nodev,noexec, etc.).
But yes, bind-mounts are an exception to the general rule. However,
they're an exception that does make your above claim questionable, at
least. btrfs subvolumes are another such exception.
In some ways the btrfs subvolume behaves like a folder. In other ways it
acts like a device. If you stat the mount point for btrfs subvolumes,
you get a unique device ID for each.
Agreed.
It seems inconsistent that mount and unmount allows a /dev/ designation,
but only mount honors label and UUID.
Yes. I had tested btrfs a year ago and decided to wait so haven't been
active here for 8 months or so, but am now getting back into btrfs as my
requirements are different now, and as I'm reading the list, I've seen
this frustrating inconsistency complained about more than once. I'm
about to setup a new btrfs system here once again, so don't yet know if
it'll affect me personally, but given that I routinely use labels in
fstab, it certainly could, depending on how the umounts are handled. But
at least I have a heads-up on the issue and can thus work around it
should I need to.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
