From: Robert White <rwhite@pobox.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Wishlist Item :: One Subvol in Multiple Places
Date: Wed, 15 Oct 2014 12:07:06 -0700 [thread overview]
Message-ID: <543EC5DA.9040905@pobox.com> (raw)
In-Reply-To: <543E5AD2.6080207@gmail.com>
On 10/15/2014 04:30 AM, Austin S Hemmelgarn wrote:
> On 2014-10-14 18:25, Robert White wrote:
>> I've got no idea if this is possible given the current storage layout,
>> but it would be Really Nice™ if there were a way to have a single
>> subvolume exist in more than one place in hirearchy. I know this can be
>> faked via mount tricks (bind or use of subvol=), but having it be a real
>> thing would be preferable.
>>
>> For example, if I have two or more distributions on a computer or want
>> to switch between 32bit and 64bit environments frequently, but I want to
>> use the same /home (which is its own subvolume anyway) it would be nice
>> if the native layout could be permuted such that /__System_32/home and
>> /__System_64/home were the actual same subvolume.
>>
>> The mechanism, were it possible, would be something like "btrfs
>> subvolume link /existing/path /new/path" (or "bind" instead of "link")
>>
>> I've got no idea if the directory structure would allow for this, but if
>> it would it would simplify several things (for me anyway) if the file
>> system layout represented the runtime layout.
> This probably won't be implemented, for the same reason that most modern
> unix systems disallow hardlinks to directories; namely, it results in
> ambiguity regarding resolution of the .. directory entry.
> The better solution would be to put /home in a separate top-level
> sub-volume, and then mount that in each location.
Oh. Duh. I knew that...
Some days the brain, you know... 8-)
--Rob.
prev parent reply other threads:[~2014-10-15 19:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-14 22:25 Wishlist Item :: One Subvol in Multiple Places Robert White
2014-10-15 11:30 ` Austin S Hemmelgarn
2014-10-15 19:07 ` Robert White [this message]
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=543EC5DA.9040905@pobox.com \
--to=rwhite@pobox.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.