All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin <m_btrfs@ml1.co.uk>
To: linux-btrfs@vger.kernel.org
Subject: Re: Virtual Device Support
Date: Tue, 21 May 2013 13:06:04 +0100	[thread overview]
Message-ID: <knfnv7$k9h$1@ger.gmane.org> (raw)
In-Reply-To: <9BA35EA6-D116-4223-B2C0-CE4FEA3D4010@colorremedies.com>

On 21/05/13 04:37, Chris Murphy wrote:
> 
> On May 20, 2013, at 7:08 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Chris Murphy posted on Sun, 19 May 2013 12:18:19 -0600 as
>> excerpted:
>> 
>>> It seems inconsistent that mount and unmount allows a /dev/
>>> designation, but only mount honors label and UUID.
>> 
>> Yes.
> 
> I'm going to contradict myself and point out that mount with label or
> UUID is made unambiguous via either the default subvolume being
> mounted, or the -o subvol= option being specified. The volume label
> and UUID doesn't apply to umount because it's an ambiguous command.
> You'd have to umount a mountpoint, or possibly a subvolume specific
> UUID.


I'll admit that I prefer working with filesystem labels.


This is getting rather semantic... From "man umount", this is what
umount intends:

#####
umount [-dflnrv] {dir|device}...

The  umount  command  detaches the file system(s) mentioned from the
file hierarchy.  A file system is specified by giving the directory
where it has been mounted.  Giving the special device on which the file
system lives may also work, but is obsolete, mainly because it will fail
in case this device was mounted on more than one directory.
#####


I guess the ideas of labels and UUID and multiple devices came out a few
years later?... For btrfs, umount needs to operate on the default subvol
but with the means for also specifying a specific subvol if needed.

One hook for btrfs to extend what/how 'umount' operates might be to
perhaps extend what can be done with a "/sbin/(u?)mount.btrfs" 'helper'?


Regards,
Martin


  reply	other threads:[~2013-05-21 12:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-10 14:03 Virtual Device Support George Mitchell
2013-05-19 11:04 ` Martin
2013-05-19 14:49   ` George Mitchell
2013-05-19 17:18     ` Martin
     [not found]     ` <CAHGunUke143r3pj0Piv3AtJrJO1x8Bm+qS5Z+sY1G1EobhMG_w@mail.gmail.com>
2013-05-21 14:26       ` George Mitchell
2013-05-19 11:15 ` Roman Mamedov
2013-05-19 18:18   ` Chris Murphy
2013-05-19 18:22     ` Chris Murphy
2013-05-21  1:08     ` Duncan
2013-05-21  2:17       ` George Mitchell
2013-05-21  3:59         ` Duncan
2013-05-21  5:21           ` George Mitchell
2013-05-21 12:19           ` Virtual Device Support ("N-way mirror code") Martin
2013-05-23 16:08             ` Martin Steigerwald
2013-05-24  1:41               ` George Mitchell
2013-05-25 11:53                 ` Martin Steigerwald
2013-05-24  6:13               ` Duncan
2013-05-25 11:56                 ` Martin Steigerwald
2013-05-21  3:37       ` Virtual Device Support Chris Murphy
2013-05-21 12:06         ` Martin [this message]
2013-05-22  2:23           ` Chris Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='knfnv7$k9h$1@ger.gmane.org' \
    --to=m_btrfs@ml1.co.uk \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.