Re: [PATCH 0/2] btrfs: allow cross-subvolume BTRFS_IOC_CLONE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christoph,

On Sat, 2 Apr 2011 12:40:11 AM Chris Mason wrote:

> Excerpts from Christoph Hellwig's message of 2011-04-01 09:34:05 
-0400:
>
> > I don't think it's a good idea to introduce any user visible
> > operations over subvolume boundaries.  Currently we don't have
> > any operations over mount boundaries, which is pretty
> > fumdamental to the unix filesystem semantics.  If you want to
> > change this please come up with a clear description of the
> > semantics and post it to linux-fsdevel for discussion.  That of
> > course requires a clear description of the btrfs subvolumes,
> > which is still completely missing.
> 
> The subvolume is just a directory tree that can be snapshotted, and
> has it's own private inode number space.
> 
> reflink across subvolumes is no different from copying a file from
> one subvolume to another at the VFS level.  The src and
> destination are different files and different inodes, they just
> happen to share data extents.

Were Chris Mason's points above enough to sway your opposition to this 
functionality/patch?

There is demand for the ability to move data between subvolumes 
without needing to copy the extents themselves, it's cropped up again 
on the list in recent days.

It seems a little hard (and counterintuitive) to enforce a wasteful 
use of resources to copy data between different parts of the same 
filesystem which happen to be a on a different subvolume when it's 
permitted & functional to the same filesystem on the same subvolume.

I don't dispute the comment about documentation on subvolumes though, 
there is a short discussion of them on the btrfs wiki in the sysadmins 
guide, but not really a lot of detail. :-)

All the best,
Chris
-- 
 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

This email may come with a PGP signature as a file. Do not panic.
For more info see: http://en.wikipedia.org/wiki/OpenPGP

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux