From: Christoph Anton Mitterer <calestyo@scientia.net>
To: linux-btrfs@vger.kernel.org
Subject: subvols and parents - how?
Date: Tue, 24 Nov 2015 05:56:00 +0100 [thread overview]
Message-ID: <1448340960.14125.51.camel@scientia.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 2083 bytes --]
Hey.
I'd have a, mainly administrative, question.
When I use subvolumes than these have always a parent subvolume (except
ID5), so I can basically decide between two ways:
a) make child subvolumes, e.g.
5
|
+-root (=subvol, mountpoint /)
+-boot/
+-root/
+-lib/
+-home/ (=subvolume)
and soon on... perhaps the whole thing without the dedicated root-
subovlume (although that's probably not so smart, I guess).
b) place at least some of the subvolumes directly below the top-level
and mount them e.g. via /etc/fstab, e.g.
5
|
+-root (=subvol, mountpoint /)
| +-boot/
| +-root/
| +-lib/
+-home/ (=subvolume, mountpoint /home)
Now I wondered whether this has any technical implications, but neither
the wiki, nor the manpages seem to explain a lot here.
The "differences", AFAIU, are the follows:
- When I mount a given subvolume,.. it's childs are automatically
"there".
Whereas when I don't have them as childs (as in (b)) I must of
course mount them somehow manually.
- Analogously for umounting.
- I can move existing subvols to higher/lower levels, and the parent
IDs will change accordingly.
So basically it makes no difference, right? Or is there anything more
technical going on? E.g. with the ref-links or so?
Right now, there are, AFAIK, neither recursive snapshots (and
especially not atomic ones) nor recursive send/receive, right?
If that should ever be implemented, would I perhaps have problems with
(a) or (b)?
Thanks,
Chris.
btw, for a developer:
$ btrfs subvolume list /mnt/ -pacguqt
ID gen cgen parent top level parent_uuid uuid path
-- --- ---- ------ --------- ----------- ---- ----
257 16 8 5 5 - 64f8a75b-5cb5-6e4d-9f30-d45fe3d9e060 <FS_TREE>/root
There seem to be some colum mis-aglinment issues in the output =)
btrfsprogs 4.3
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]
next reply other threads:[~2015-11-24 4:56 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 4:56 Christoph Anton Mitterer [this message]
2015-11-24 8:29 ` subvols and parents - how? Duncan
2015-11-24 21:25 ` Christoph Anton Mitterer
2015-11-24 21:55 ` Hugo Mills
2015-11-24 23:20 ` Christoph Anton Mitterer
2015-11-24 23:30 ` Hugo Mills
2015-11-24 23:38 ` Christoph Anton Mitterer
2015-11-27 1:02 ` Duncan
2015-12-09 4:36 ` Christoph Anton Mitterer
2015-12-09 10:53 ` Duncan
2015-12-09 19:04 ` Austin S Hemmelgarn
2015-12-10 3:56 ` Duncan
2015-12-10 12:31 ` Austin S Hemmelgarn
2015-12-12 19:58 ` Christoph Anton Mitterer
2015-11-27 2:02 ` Duncan
2015-12-09 4:38 ` Christoph Anton Mitterer
2015-12-09 11:26 ` Duncan
2015-12-10 21:13 ` subvols, ro- and bind mounts " Christoph Anton Mitterer
2015-12-10 22:36 ` S.J.
2015-12-10 23:41 ` Christoph Anton Mitterer
2015-12-11 2:32 ` Chris Murphy
2015-12-12 20:27 ` Christoph Anton Mitterer
2015-12-12 2:32 ` subvols and parents " Christoph Anton Mitterer
2015-12-12 3:07 ` Christoph Anton Mitterer
2015-12-12 10:20 ` Duncan
2015-12-09 14:49 ` Axel Burri
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=1448340960.14125.51.camel@scientia.net \
--to=calestyo@scientia.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.