All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Moving an entire subvol?
Date: Sun, 30 Nov 2014 17:54:44 -0700	[thread overview]
Message-ID: <CAJCQCtT3EeGUOpZ9q78BcWv_Cc_5UGY=uPVJX+bqex9Zo_bWYg@mail.gmail.com> (raw)
In-Reply-To: <CAH-HCWVcu9FW0c3zwEg_KR_yaPGRQ58yHbXsUx1JCKRu4s7NXQ@mail.gmail.com>

On Sat, Nov 29, 2014 at 8:31 PM, Shriramana Sharma <samjnaa@gmail.com> wrote:
> So the Ubuntu Wiki BtrFS entry advises against using subvol
> set-default because it boots its kernel using root=subvol=@ and home
> as subvol=@home, and these two subvols are only present under the
> subvol with ID 5.

The advice may have had to do with GRUB behavior prior to 2.02.
Previously GRUB attempted to honor the btrfs default subvolume, and
therefore treated any path in grub.cfg relative to the default
subvolume. Now, GRUB behaves the same as the subvol= mount option, it
is always treated as an absolute path from subvol id 5, hence the
default subvolume is ignored.

Since the default subvolume is set by a user space program I think
it's a domain violation for anything to subvert this; it really should
remain a shortcut for the user's benefit only, so they can use mount
without -o subvol=. Everything else should explicitly pass subvol=



> But isn't it just possible to move i.e. reparent a
> subvol so I can move these two under another subvol and have that as
> default?

You can move subvolumes. My suggestion is subvolumes containing
binaries shouldn't be located within another subvolume that ends up
being mounted, that way old binaries with possible vulnerabilities
aren't exposed in the normal search path.

>
> Possibly this is a hypothetical question as I'm not sure whether it
> would be actually practically required but looking at the specific
> Ubuntu advice on this I thought I should ask.
>
> I'm also not sure what openSUSE (or other distros) do about this... Do
> they mount root using subvolid, or subvol name or such?

openSUSE uses subvol id 5 for installing the OS to, and some
directories are made subvolumes such as home var and maybe usr.
Therefore when subvolid 5 is snapshot, those are exempt, and have to
be individually snapshot. The snapshots are found in the same root
directory everything else is, in a . directory (I think .snapshots ?)

Fedora uses subvolumes root and home by default, and fstab uses
subvol=root and subvol=home to mount them at / and /home respectively.

I don't know any distro using subvolid right now but that might be
prudent as it's far less user domain than subvolume names.


-- 
Chris Murphy

  parent reply	other threads:[~2014-12-01  0:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-30  3:31 Moving an entire subvol? Shriramana Sharma
2014-11-30  4:21 ` Marc MERLIN
2014-11-30 10:27   ` Shriramana Sharma
2014-12-01  0:10     ` Marc MERLIN
2014-12-01  0:54 ` Chris Murphy [this message]
2014-12-02  3:21   ` Shriramana Sharma
2014-12-02  8:34     ` Hugo Mills
2014-12-03  2:32       ` Shriramana Sharma
2014-12-03  8:37         ` Hugo Mills
2014-12-02  8:50     ` Duncan
2014-12-02 13:28     ` David Sterba
2014-12-02 15:11       ` Shriramana Sharma
2014-12-02 20:30         ` Robert White
2014-12-02 21:13         ` Austin S Hemmelgarn
2014-12-03  2:33           ` Shriramana Sharma
2014-12-05 17:34         ` David Sterba

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='CAJCQCtT3EeGUOpZ9q78BcWv_Cc_5UGY=uPVJX+bqex9Zo_bWYg@mail.gmail.com' \
    --to=lists@colorremedies.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.