Re: What to do about subvolumes?

[Martin Steigerwald <Martin@lichtvoll.de>]

[-- Attachment #1: Type: Text/Plain, Size: 2618 bytes --]

Am Mittwoch 01 Dezember 2010 schrieb Mike Hommey:
> On Wed, Dec 01, 2010 at 11:01:37AM -0500, Chris Mason wrote:
> > Excerpts from C Anthony Risinger's message of 2010-12-01 09:51:55 
-0500:
> > > On Wed, Dec 1, 2010 at 8:21 AM, Josef Bacik <josef@redhat.com> 
wrote:
> > > > === How do we want subvolumes to work from a user perspective?
> > > > ===
> > > > 
> > > > 1) Users need to be able to create their own subvolumes. Â The
> > > > permission semantics will be absolutely the same as creating
> > > > directories, so I don't think this is too tricky. Â We want this
> > > > because you can only take snapshots of subvolumes, and so it is
> > > > important that users be able to create their own discrete
> > > > snapshottable targets.
> > > > 
> > > > 2) Users need to be able to snapshot their subvolumes. Â This is
> > > > basically the same as #1, but it bears repeating.
> > > 
> > > could it be possible to convert a directory into a volume?  or at
> > > least base a snapshot off it?
> > 
> > I'm afraid this turns into the same complexity as creating a new
> > volume and copying all the files/dirs in by hand.
> 
> Except you wouldn't have to copy data, only metadata.

And it could probably be race-free. If I'd  cp -reflink or rsync stuff from 
a real directory to a subvolume and then rename the old directory to an 
other name and the subvolume to the directory name then I might be missing 
files that have been created during the copy process and missing changes to 
files that have been already copied.

What I would like is an easy way to make ~/.kde or whatever a subvolume to 
be able to snapshot it independently while KDE applications or whatever is 
using and writing to it, *without* any userland even noticing it and 
without - except for metadata for managing the subvolume - any additional 
space consumption.

So

deepdance:/#12> btrfs subvolume create /home/martin/.kde
ERROR: '/home/martin/.kde' exists

would just make a subvolume out of ~/.kde even if it needs splitting out 
the tree or even copying the tree data into a new tree.

There are other filesystem operations like btrfs filesystem balance that can 
be expensive as well.

All that said from a user point of view. Maybe technical its not feasible. 
But it would be nice if it can be made feasible without loosing existing 
advantages.

And maybe

deepdance:/> btrfs subvolume create .   
ERROR: '.' exists

should really remain this way ;).

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]