All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Mitchell <george@chinilu.com>
To: unlisted-recipients:; (no To-header on input)
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Virtual Device Support
Date: Sun, 19 May 2013 07:49:44 -0700	[thread overview]
Message-ID: <5198E688.30402@chinilu.com> (raw)
In-Reply-To: <knabiu$akg$1@ger.gmane.org>

In reply to both of these comments in one message, let me give you an 
example.

I use shell scripts to mount and unmount btrfs volumes for backup 
purposes.  Most of these volumes are not listed in fstab simply because 
I do not want to have to clutter my fstab with volumes that are used 
only for backup.  So the only way I can mount them is either by LABEL or 
by UUID.  But I can't unmount them by either LABEL or UUID because that 
is not supported by util-linux and they have no intention of supporting 
it in the future.  So I have to resort to unmounting by directory and it 
becomes back and forth between LABEL and directory which becomes very 
confusing when you are dealing with complex shell scripts.  This is 
intolerable for me so I use a kludge that allows me to first translate 
from LABEL to device and then unmount by device.  To me it just seems 
klutzy that one has to resort to these sorts of games to use a file 
system that is supposed to be an improvement on what we already have.  A 
simple virtual volume identifier would resolve that. Doing the same for 
subvolumes would be nice, but I could live without it with no problem.  
I have worked with nixes for 30 years beginning with AT&T pre-SRV on 
DEC-1170s and have seen a lot of changes since those days, most of them 
for the better.  But, while functionality is mandatory, convenience is 
always appreciated and can help avoid costly mistakes and save time.  As 
I stated in my original post, I KNOW and appreciate that all of you are 
working hard on things that matter far more than this trivial item.  But 
it is a major convenience and clarity issue for me and I am sure it will 
be for others as well.  It is only rational that one should be able to 
expect to mount by LABEL and unmount by LABEL, but that doesn't work, 
and a major part of the reason that doesn't work is that btrfs does not 
conform to the pattern of just about every other file system on the 
planet in regards to how it treats mount points.  And this is not even 
to mention all the other issues involved like a large number of 
utilities that have no way of knowing that a given partition is mounted, 
which would also be resolved by virtual mount points since many if not 
most of those utilities understand and process virtual volume identifiers.

Please just do me a favor and think about this a bit before you just 
write it off.

- George



On 05/19/2013 04:04 AM, Martin wrote:
> On 10/05/13 15:03, George Mitchell wrote:
>> One the things that is frustrating me the most at this point from a user
>> perspective ...  The current method of simply using a
>> random member device or a LABEL or a UUID is just not working well for
>> me.  Having a well thought out virtual device infrastructure would...
> Sorry, I'm a bit lost for your comments...
>
> What is your use case and what are you hoping/expecting to see?
>
>
> I've been following development of btrfs for a while and I'm looking
> forward to use it to efficiently replace some of the very useful
> features of LVM2, drbd, and md-raid that I'm using at present...
>
> OK, so the way of managing all that is going to be a little different.
>
> How would you want that?
>
>
> Regards,
> Martin
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

On 05/19/2013 04:15 AM, Roman Mamedov wrote:
> On Fri, 10 May 2013 07:03:38 -0700
> George Mitchell <george@chinilu.com> wrote:
>
>> One the things that is frustrating me the most at this point from a user
>> perspective regarding btrfs is the current lack of virtual devices to
>> describe volumes and subvolumes.
>  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.
>

  reply	other threads:[~2013-05-19 14:49 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 [this message]
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
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=5198E688.30402@chinilu.com \
    --to=george@chinilu.com \
    --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.