Moving an entire subvol?

Moving an entire subvol?

[Shriramana Sharma]

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. 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?

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?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Moving an entire subvol?

[Marc MERLIN]

On Sun, Nov 30, 2014 at 09:01:42AM +0530, Shriramana Sharma 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. 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?

Make a new subvolume called /root and just mount subvol=root
Note that you can't mount subvols recursively in one mount AFAIK.

This is what my system looks like:
LABEL=btrfs_pool1 /               btrfs    subvol=root,defaults,compress=lzo,discard,skip_balance,noatime 0       0
LABEL=btrfs_pool1 /usr            btrfs    subvol=usr,defaults,compress=lzo,discard,skip_balance,noatime  0       0
LABEL=btrfs_pool1 /var            btrfs    subvol=var,defaults,compress=lzo,discard,skip_balance,noatime  0       0
LABEL=btrfs_pool1 /home           btrfs    subvol=home,defaults,compress=lzo,discard,skip_balance,noatime 0       0
LABEL=btrfs_pool1 /tmp            btrfs    subvol=tmp,defaults,compress=lzo,discard,skip_balance,noatime,noexec  0       0
LABEL=btrfs_pool1 /mnt/btrfs_pool1 btrfs   defaults,compress=lzo,discard,skip_balance,noatime,subvolid=0         0       0

Hope this helps.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

Re: Moving an entire subvol?

[Shriramana Sharma]

On Sun, Nov 30, 2014 at 9:51 AM, Marc MERLIN <marc@merlins.org> 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. 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?
>
> Make a new subvolume called /root and just mount subvol=root

Sorry if my question wasn't clear: I wanted to know how to move a
subvol to appear under another subvol other than its original parent.
Turns out that sudo mv @ @home target/ is quite sufficient. If so why
would the Ubuntu wiki require that set-default not be used? Just @
@home need to be moved to the new place, no?

> Note that you can't mount subvols recursively in one mount AFAIK.

I'm not sure what you mean. I have a few subvols in my external HDD
which is entirely formatted as BtrFS and if I just mount the external
HDD /dev/sdc1 I am able to access all the subvols' contents as well.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Moving an entire subvol?

[Marc MERLIN]

On Sun, Nov 30, 2014 at 03:57:06PM +0530, Shriramana Sharma wrote:
> On Sun, Nov 30, 2014 at 9:51 AM, Marc MERLIN <marc@merlins.org> 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. 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?
> >
> > Make a new subvolume called /root and just mount subvol=root
> 
> Sorry if my question wasn't clear: I wanted to know how to move a
> subvol to appear under another subvol other than its original parent.
> Turns out that sudo mv @ @home target/ is quite sufficient. If so why
> would the Ubuntu wiki require that set-default not be used? Just @
> @home need to be moved to the new place, no?

I've never done that. If I had to move them, I'd just change the
mountpoint.
 
> > Note that you can't mount subvols recursively in one mount AFAIK.
> 
> I'm not sure what you mean. I have a few subvols in my external HDD
> which is entirely formatted as BtrFS and if I just mount the external
> HDD /dev/sdc1 I am able to access all the subvols' contents as well.

Yes, if you mount the root, it works of course.
If you mount a subvol, you cannot have it automatically have it mount
other subvols.
Subvols don't really know or care where they are mounted compared to one
another, and who is under whom. It's just mount setup.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/                         | PGP 1024R/763BE901

Re: Moving an entire subvol?

[Chris Murphy]

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

Re: Moving an entire subvol?

[Shriramana Sharma]

On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy <lists@colorremedies.com> wrote:
>> 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.

OK so I just found out that just mv test1/foo test2/ where test1,
test2 and foo are all subvolumes is sufficient to reparent foo to
test2, if what btr sub list shows as "top level" is indeed the parent
subvolume.

Is that correct: what btr sub list shows as "top level" is indeed the
parent subvolume?

> 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.

I'm not sure what you mean. Are you saying that for example /usr/bin should be:

1) a separate subvolume than / or /usr,
2) not a child subvolume of / or /usr?

> 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.

Yes I also noticed that openSUSE creates such separate subvols, but is
there any particular benefit to making it so?

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

This seems similar to Ubuntu's @ and @home setup.

Is there any advantage to either? That is, one model installs root to
the topmost subvol and makes usr, home etc nested subvols, whereas
another makes root a nested subvol under the topmost just like usr
home etc, and then mounts it to /...

In general it seems people (or at least distros) prefer avoiding
nesting subvolumes. Is there any particular reason for this? Esp in
regard to /usr etc it would seem that if they are nested within the
subvol for /, then just mounting that subvol would automatically mount
all nested subvolumes, right? So the extra effort needed to mount the
nested subvols would not be necessary, no?

Shriramana.

Re: Moving an entire subvol?

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 3661 bytes --]

On Tue, Dec 02, 2014 at 08:51:40AM +0530, Shriramana Sharma wrote:
> On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy <lists@colorremedies.com> wrote:
> >> 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.
> 
> OK so I just found out that just mv test1/foo test2/ where test1,
> test2 and foo are all subvolumes is sufficient to reparent foo to
> test2, if what btr sub list shows as "top level" is indeed the parent
> subvolume.
> 
> Is that correct: what btr sub list shows as "top level" is indeed the
> parent subvolume?

   No, it's the top-level subvolume. (See my earlier mail about
nomenclature). "Parent subvolume" has a number of meanings, none of
which should be "the subvolume with subvolid 5".

> > 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.
> 
> I'm not sure what you mean. Are you saying that for example /usr/bin should be:
> 
> 1) a separate subvolume than / or /usr,
> 2) not a child subvolume of / or /usr?
> 
> > 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.
> 
> Yes I also noticed that openSUSE creates such separate subvols, but is
> there any particular benefit to making it so?

   In the sense of allowing independent snapshotting, yes. I might
want to back up / (with usr, var, and so forth) only when I do a
system upgrade, but /home every night. Making /home a separate subvol
gives me the ability to snapshot those two areas independently.

> > Fedora uses subvolumes root and home by default, and fstab uses
> > subvol=root and subvol=home to mount them at / and /home respectively.
> 
> This seems similar to Ubuntu's @ and @home setup.
> 
> Is there any advantage to either? That is, one model installs root to
> the topmost subvol and makes usr, home etc nested subvols, whereas
> another makes root a nested subvol under the topmost just like usr
> home etc, and then mounts it to /...
> 
> In general it seems people (or at least distros) prefer avoiding
> nesting subvolumes. Is there any particular reason for this? Esp in
> regard to /usr etc it would seem that if they are nested within the
> subvol for /, then just mounting that subvol would automatically mount
> all nested subvolumes, right? So the extra effort needed to mount the
> nested subvols would not be necessary, no?

   Nested subvols tend to get messy in practice. It's harder to
replace a "higher level" one, because you've got to move the "lower
level" ones around. It's also much harder to make a send/receive
backup of the subvols in their original relationships, because of the
read-only requirement.

   Whilst the theory came first, several years of practice has shown
both that nesting subvolumes is generally more awkward to manage, and
that putting files in the top-level subvol can't do what most people
want to do with it. Hence the recommended subvol management layout at
[1].

   Hugo.

[1] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes

-- 
Hugo Mills             | We teach people management skills by examining
hugo@... carfax.org.uk | characters in Shakespeare. You could look at
http://carfax.org.uk/  | Claudius's crisis management techniques, for
PGP: 65E74AC0          | example.       Richard Smith-Jones, Slings and Arrows

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Moving an entire subvol?

[Duncan]

Shriramana Sharma posted on Tue, 02 Dec 2014 08:51:40 +0530 as excerpted:

> On Mon, Dec 1, 2014 at 6:24 AM, Chris Murphy <lists@colorremedies.com>
> wrote:
>>> 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.
> 
> OK so I just found out that just mv test1/foo test2/ where test1,
> test2 and foo are all subvolumes is sufficient to reparent foo to test2,
> if what btr sub list shows as "top level" is indeed the parent
> subvolume.
> 
> Is that correct: what btr sub list shows as "top level" is indeed the
> parent subvolume?

[Noting that my use-case doesn't involve subvolumes so while I've played 
with them a bit my direct knowledge is limited...]

It should be correct, yes.

Subvolumes are in many ways "super-directories", so it's little surprise 
simply directory manipulation such as moves would do what you might 
expect.  They just happen to be directly mountable too, and to have 
various btrfs-specific effects such as snapshots stopping at subvolume 
boundaries, usage for btrfs send/receive, etc.

>> 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.
> 
> I'm not sure what you mean. Are you saying that for example /usr/bin
> should be:
> 
> 1) a separate subvolume than / or /usr,
> 2) not a child subvolume of / or /usr?

What I believe he's referencing is the potential security issue if for 
example you have older snapshots of /usr (which would include /usr/bin 
and /usr/lib(64)) accessible under normal operating conditions.  These 
snapshots would contain older versions of binaries (and libraries) that 
have been security-updated on the main system, but the snapshots would of 
course contain the still vulnerable versions.  A user trying to do a root-
escalation, for instance, could then access and run one of these old and 
vulnerable versions by specifying the full path instead of just the name, 
thus getting access to a known root-escalation vuln long since patched in 
the main path but still vulnerable in the snapshot path.

If for instance the master id=5 subvolume is still the default and 
routinely mounted, it will have all snapshots appearing as directories 
somewhere beneath its mountpoint in the tree.  If those snapshots contain 
bin or lib dirs, the above security scenario is a real possibility, since 
they'll be accessible in the tree.

So making something other than the master id=5 subvolume the default, 
mounting id=5 only when doing subvolume maintenance not routinely, and 
making such bin/lib-containing snapshots direct children of id=5 instead 
of children of the / subvolume or the like, will keep the snapshots 
containing the possibly vulnerable bins/libs out of normal accessibility 
as they'll only be visible in the tree when id=5 is mounted for snapshot 
maintenance, etc.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Moving an entire subvol?

[David Sterba]

On Tue, Dec 02, 2014 at 08:51:40AM +0530, Shriramana Sharma wrote:
> > 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.
> 
> Yes I also noticed that openSUSE creates such separate subvols, but is
> there any particular benefit to making it so?

A subvolume is also a snapshotting barrier, so it's convenient to create
subvolumes in well-known paths that contain data that should not be
rolled back (/var/log, /srv, bootloader).

Re: Moving an entire subvol?

[Shriramana Sharma]

On Tue, Dec 2, 2014 at 6:58 PM, David Sterba <dsterba@suse.cz> wrote:
>
> A subvolume is also a snapshotting barrier, so it's convenient to create
> subvolumes in well-known paths that contain data that should not be
> rolled back (/var/log, /srv, bootloader).

Hi David -- a real honour to meet one of the core Btrfs/SuSE (heh,
when that was the spelling!) guys!

That makes sense. Is there anywhere that the "official" SuSE
recommended subvol layout is mentioned that I can refer to without
having to start up an installer? (I currently chose ext4 for / for
other reasons so I can't refer to my layout.)

I am now reading a SuSECon 2013 presentation by Nyers and Schnell but
they are very generic about the recommendations.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Moving an entire subvol?

[Robert White]

On 12/02/2014 07:11 AM, Shriramana Sharma wrote:
> On Tue, Dec 2, 2014 at 6:58 PM, David Sterba <dsterba@suse.cz> wrote:
>>
>> A subvolume is also a snapshotting barrier, so it's convenient to create
>> subvolumes in well-known paths that contain data that should not be
>> rolled back (/var/log, /srv, bootloader).

> That makes sense. Is there anywhere that the "official" SuSE
> recommended subvol layout is mentioned that I can refer to without
> having to start up an installer? (I currently chose ext4 for / for
> other reasons so I can't refer to my layout.)

There are lots of ways to arrange your system

My preference is to create the snapshots in a super-volume outside of 
the normally mounted hierarchy. This simplifies the normal operation of 
tools like "locate" which don't understand that the duplicate files from 
the snapshot are not interesting. It also means that live operations 
(e.g. anything using "find") naturally will not traverse the snapshots 
unless the supervolume is mounted explicitly.

I typically call the active root of the system /__System and set it as 
the default subvolume to make booting easier.

As in...

mkfs.btrfs /dev/whatever
mount /dev/whatever /mnt
btrfs sub create /mnt/__System
btrfs sub create /mnt/__System/home
btrfs sub set-default (number) /mnt
umount /mnt
mount /mnt
(create OS layout in /mnt)


Then when the snapshotting goes on...

mount -o subvol=/ /dev/whatever /maintenance
SUFFIX=$(date "+_BACKUP_%Y-%M-%d")
cd /maintenance
btrfs sub snap -r __System __System${SUFFIX}
btrfs sub snap -r __System/home __System_home${SIFFIX}
# etc
cd /
umount /maintenance


---

The Real Way™ to think about your active subvolume layouts is to think 
about what you really need to preserve and how often.

/home is an obvious candidate for frequent snapshots as it is the place 
individual users are most likely to mess up, and it has the most 
"irreplaceable" data.

/ (e.g. the semantic system root) [in my example /__System] [not 
counting its various subvolumes really only needs backing up before 
system software modifications via apt/yumm/portage/wahtever your distro 
uses. Or right before you start doing aything "tricky" in /etc

/etc  might rate its own subvolume if you are a tinker or your 
system-wide configuration needs a lot of motility.

/var tends to have per system configuration stuff


But the real question is "how much complexity of maintenance does the 
system _really_ need, and how much of it are you _really_ going to maintain.

The desire to use a feature "just 'cause it's there" should be resisted. 
If you are not going to be using the snapshots feature. If you are just 
dropping the box in and you are going to ignore it, then don't subvolume 
it at all.

You are looking for a balance between the theoretical ideal and the 
practical outcome. If you don't know exactly why you are putting the 
subvolume in place then it will likely just end up annoying you without 
giving any value.

Same for taking and positioning the snapshots.

This is a corollary of the rule that states "A backup script that you've 
never done a restore from, should be assumed to be an _unsafe_ or 
complete backup, or no backup at all."

Re: Moving an entire subvol?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]

On 2014-12-02 10:11, Shriramana Sharma wrote:
> On Tue, Dec 2, 2014 at 6:58 PM, David Sterba <dsterba@suse.cz> wrote:
>>
>> A subvolume is also a snapshotting barrier, so it's convenient to create
>> subvolumes in well-known paths that contain data that should not be
>> rolled back (/var/log, /srv, bootloader).
>
> Hi David -- a real honour to meet one of the core Btrfs/SuSE (heh,
> when that was the spelling!) guys!
>
> That makes sense. Is there anywhere that the "official" SuSE
> recommended subvol layout is mentioned that I can refer to without
> having to start up an installer? (I currently chose ext4 for / for
> other reasons so I can't refer to my layout.)
>
> I am now reading a SuSECon 2013 presentation by Nyers and Schnell but
> they are very generic about the recommendations.
>
Here's my approach to things:
In the top level of the btrfs filesystem I use for /, I have a subvolume 
called /root,  This is what get's mount on /.  I also have a separate 
subvolume called /home for the home directories when I have those on the 
same FS.  I place /boot on an entirely separate filesystem because I use 
a bunch of mount options there that would break or slow down other 
filesystems (most notably, noexec, nosuid, nodev, and sync).  Within 
both /home and /root, I use a handful of subvolumes to control what gets 
saved in a snapshot, the most notable examples being /var//log, 
/usr/portage, and /home/austin/dropbox.

As far as snapshots go, I take a snapshot of /root every time I boot, 
and keep the past 2 days worth, take a snapshot of /home hourly, and 
keep a weeks worth, and do a snapshot of both when I generate a system 
backup.  I generally don't do snapshots of /boot, as I keep around the 
previous few kernel versions anyway, and mark things there as immutable 
so that I can't accidentally mess them up.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Moving an entire subvol?

[Shriramana Sharma]

On Tue, Dec 2, 2014 at 2:04 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
>
>> Is that correct: what btr sub list shows as "top level" is indeed the
>> parent subvolume?
>
>    No, it's the top-level subvolume. (See my earlier mail about
> nomenclature). "Parent subvolume" has a number of meanings, none of
> which should be "the subvolume with subvolid 5".

Um I searched my inbox but didn't find a specific definition from you
for "top-level". You only said it's better to avoid calling it "root"
to avoid confounding it with the subvol that may be mounted at root
i.e. /.

IIUC the "top-level subvolume" can only be subvolid 5 which accords
with your later comment:

> that putting files in the top-level subvol can't do what most people
> want to do with it. Hence the recommended subvol management layout at
> [1] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes

... which means that I am not able to understand the output of btr sub
list which gives the subvolid of whichever subvol is currently the
"parent" (as in outer nesting) subvol. Observe:

$ btr sub list .
ID 257 gen 10 top level 5 path test1
ID 258 gen 10 top level 5 path test2
ID 259 gen 9 top level 258 path test2/foo
$ sudo mv test2/foo test1/
$ btr sub list .
ID 257 gen 10 top level 5 path test1
ID 258 gen 10 top level 5 path test2
ID 259 gen 9 top level 257 path test1/foo
$

So now what is the meaning of "top level"?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Moving an entire subvol?

[Shriramana Sharma]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 414 bytes --]

On Wed, Dec 3, 2014 at 2:43 AM, Austin S Hemmelgarn
<ahferroin7@gmail.com> wrote:
> Here's my approach to things:

Wow, thanks a lot people! I'm really benefiting from your experience here.

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ý»k~ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

Re: Moving an entire subvol?

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On Wed, Dec 03, 2014 at 08:02:31AM +0530, Shriramana Sharma wrote:
> On Tue, Dec 2, 2014 at 2:04 PM, Hugo Mills <hugo@carfax.org.uk> wrote:
> >
> >> Is that correct: what btr sub list shows as "top level" is indeed the
> >> parent subvolume?
> >
> >    No, it's the top-level subvolume. (See my earlier mail about
> > nomenclature). "Parent subvolume" has a number of meanings, none of
> > which should be "the subvolume with subvolid 5".
> 
> Um I searched my inbox but didn't find a specific definition from you
> for "top-level". You only said it's better to avoid calling it "root"
> to avoid confounding it with the subvol that may be mounted at root
> i.e. /.

   It was the first line I wrote in my first reply to your thread
about subvol 5 vs subvol 0. I had hoped to be both definitive and
comprehensive.

> IIUC the "top-level subvolume" can only be subvolid 5 which accords
> with your later comment:
> 
> > that putting files in the top-level subvol can't do what most people
> > want to do with it. Hence the recommended subvol management layout at
> > [1] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes
> 
> ... which means that I am not able to understand the output of btr sub
> list which gives the subvolid of whichever subvol is currently the
> "parent" (as in outer nesting) subvol. Observe:
> 
> $ btr sub list .
> ID 257 gen 10 top level 5 path test1
> ID 258 gen 10 top level 5 path test2
> ID 259 gen 9 top level 258 path test2/foo
> $ sudo mv test2/foo test1/
> $ btr sub list .
> ID 257 gen 10 top level 5 path test1
> ID 258 gen 10 top level 5 path test2
> ID 259 gen 9 top level 257 path test1/foo
> $
> 
> So now what is the meaning of "top level"?

   Urgh. I haven't seriously looked at that piece of output in a
while. That's broken, in my opinion. Here, "top level" means
"containing subvolume ID".

   Hugo.

-- 
Hugo Mills             | "I don't like the look of it, I tell you." "Well,
hugo@... carfax.org.uk | stop looking at it, then."
http://carfax.org.uk/  |
PGP: 65E74AC0          |                                             The Goons

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Moving an entire subvol?

[David Sterba]

On Tue, Dec 02, 2014 at 08:41:35PM +0530, Shriramana Sharma wrote:
> That makes sense. Is there anywhere that the "official" SuSE
> recommended subvol layout is mentioned that I can refer to without
> having to start up an installer?

https://www.suse.com/documentation/sles-12/singlehtml/book_sle_admin/book_sle_admin.html#sec.snapper.setup
"Directories that are Excluded from Snapshots"

> I am now reading a SuSECon 2013 presentation by Nyers and Schnell but
> they are very generic about the recommendations.

There are some recommended defaults that should be ok, the configuration
is flexible and the user can tune the settings later according to the
usage pattern (expected amount of data changes between snapshots,
frequency of changes).