All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Mitchell <george@chinilu.com>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Virtual Device Support
Date: Mon, 20 May 2013 19:17:39 -0700	[thread overview]
Message-ID: <519AD943.6060303@chinilu.com> (raw)
In-Reply-To: <pan$d75cf$ec7daeb9$c2cc055b$98b478d0@cox.net>

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@romanrm.ru> 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.
>


  reply	other threads:[~2013-05-21  2:17 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 [this message]
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
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=519AD943.6060303@chinilu.com \
    --to=george@chinilu.com \
    --cc=1i5t5.duncan@cox.net \
    --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.