linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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