Odd BTRFS COW behaviour

[James Hogarth]

On 17 January 2014 17:52, James Hogarth <james.hogarth at gmail.com> wrote:

>
>
> Filed https://bugzilla.redhat.com/show_bug.cgi?id=1054903 to get the
> anaconda point of view and a decision on default layout for a BTRFS based
> Fedora system.
>
>
So I moved my home from being alongside root in subvolid=0 to being under
root instead to have a play around and work out some pros and cons of
having home a subvolume under root with no separate mount ...

Quickest gain is cp --reflink works all over now ... I can have the same
extents for ISOs in my download directory as my libvirt images saving space
and copies out of home to elsewhere are instant...

On the downside with home under rather than alongside root if a snapshot of
root is taken and then switched over to in order to revert something then
home would be 'lost' without it too being snapped over under the new root.
Although snapping and reverting root like this is an advanced operation the
resultant behaviour is quite unintuitive.

There is a work around to my x-dev reflink issue that kicked this off of
course - just mount subvolid=0 somewhere or other (say /mnt/rootvol) and
within that root and home would exist on the same device allowing the cp
--reflink to work ... which would then be seen back under the normal / and
/home ... but without knowing a fair bit of how btrfs works this would be
pretty hidden and unintuitive to the general user.

Having home as a separate mount in the same pool has other benefits as well
of course such as being able to use different mount options...

So now I feel I'm at somewhat of an impasse as to which works out best
overall and whether to solve the major cons it'd be better to have
recursive snapshot of subvolumes in btrfs-progs or whether cp (or rather
the IOCTLs called in the kernel) should recognise subvolumes mounted
separately from the same pool and carry out reflink ... or possibly bugs
both ways as useful enhancements?

Either way I'm not really sure what the optimum anaconda behavior for a
BTRFS layout would be ...

What are people's thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140118/a6b49c9e/attachment.html>