From: Goffredo Baroncelli <kreijack@inwind.it>
To: Chris Mason <clm@fb.com>
Cc: systemd-devel@lists.freedesktop.org,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
Date: Wed, 12 Mar 2014 20:12:12 +0100 [thread overview]
Message-ID: <5320B18C.9050400@inwind.it> (raw)
In-Reply-To: <53209868.5090506@fb.com>
On 03/12/2014 06:24 PM, Chris Mason wrote:
>
>
> On 03/10/2014 07:45 PM, Lennart Poettering wrote:
>> On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreijack@libero.it) wrote:
>>
>>>> Well, the name is property of the admin really. There needs to be a way
>>>> how the admin can label his subvolumes, with a potentially localized
>>>> name. This makes it unsuitable for our purpose, we cannot just take
>>>> possession of this and leave the admin with nothing.
>>>
>>> Instead of the name we can use the xattr to store these information.
>>
>> Ah, using xattrs for this is indeed an option. That way we should be able
>> attach any kind of information we like to a subvolume.
>>
>> Hmm, I figure though that there is no way currently to read xattrs off a
>> subvolume without first mounting them individually? Having to mount all
>> subvolumes before we can make sense of them and mount them to the right
>> place certainly sounds less than ideal...
>
> Ok, are we hoping to pull the xattrs off the disk before mounting
> anything? Or can we do a mount in a side directory first to scan for
> subvols?
>
> I like the idea of something like this:
>
> mount device on /search_for_fstab cd
> /search_for_fstab/<some_magic_directory_name_option_in_systemd>
>
> read xattrs on directories it finds to see where they should be
> mounted in the FS. xattrs may include mount options and special
> flags.
I am working to prototype something like that. A "mount.btrfs" command which
1) handles the rollback (i.e. the user make a snapshot which is a rollback; if something goes wrong and the machine reboot before ending the process, during the subvolume mounting phase the rollback replaces the "original" subvolume)
2) handles the automount (i.e. if a subvolume has the right xattr it is automatically mounted in the right place)
My idea is that the subvolume are grouped so:
@<name> simple subvolume
@<name>.<timestamp> snapshot of subvolume <name>
@<name>.rollback rollback subvolume
If @<name>.rollback exists, then it replace @<name> (something went wrong, the machine rebooted so the rollback have to take place of the original subvolume)
For each @<name> subvolume the following xattrs are considered:
user.btrfs.automount=1|0 the subvolume has to be automounted
user.btrfs.mntpoint=<path> subvolume mount point
So this "mount.btrsf" command should:
1) mount the root btrfs filesystem (subvolid=5) in a temporary directory
2) performing the auto rollback (this behaviour can be controlled by another xattr)
3) mount the subvolume "@" as "root" (like the default one) in the right mount point
4) for each subvolume which has user.btrfs.automount=1, it should be mounted under the path stored in the "user.btrfs.mntpoint" xattr (relative to "@" or absolute)
5) umount the btrfs filesystem mounted at #1, or better move it to a new position in order
to allow managing (snapshot) of the different subvolumes.
Thoughts ?
BR
G.Baroncelli
>
> mount the things you find
>
> umount /search_for_fstab
>
> I like that it's not actually btrfs specific, since the bind mounts
> will work for any FS. But it naturally fits the /@ namespace that we
> seem to be favoring as a collection point for snapshots and
> subvolumes.
> -chris
>
>
>
>
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2014-03-12 19:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20140307182603.GA22874@tango.0pointer.de>
2014-03-10 18:34 ` [systemd-devel] [HEADS-UP] Discoverable Partitions Spec Goffredo Baroncelli
2014-03-10 18:53 ` Kay Sievers
2014-03-10 18:59 ` Goffredo Baroncelli
2014-03-10 19:43 ` Chris Murphy
2014-03-10 20:02 ` Lennart Poettering
2014-03-10 20:21 ` Chris Mason
2014-03-10 20:53 ` Chris Murphy
2014-03-10 21:09 ` Lennart Poettering
2014-03-10 22:44 ` Goffredo Baroncelli
2014-03-10 22:39 ` Goffredo Baroncelli
2014-03-10 23:45 ` Lennart Poettering
2014-03-10 23:59 ` Alex Elsayed
2014-03-11 14:30 ` [systemd-devel] " Calvin Walton
2014-03-12 17:24 ` Chris Mason
2014-03-12 19:12 ` Goffredo Baroncelli [this message]
2014-03-12 19:31 ` Chris Murphy
2014-03-12 19:55 ` Goffredo Baroncelli
2014-03-12 23:22 ` Brendan Hide
2014-03-12 22:18 ` Goffredo Baroncelli
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=5320B18C.9050400@inwind.it \
--to=kreijack@inwind.it \
--cc=clm@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=systemd-devel@lists.freedesktop.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).