On 22/12/2011 2:24 =CE=BC=CE=BC, Chris Samuel wrote:

Christoph,

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

quoted

Excerpts from Christoph Hellwig's message of 2011-04-01 09:34:05

-0400:

quoted

quoted

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 thi=

s

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 sysadmin=

s

guide, but not really a lot of detail. :-)

All the best,
Chris

Me too wants cp --reflink across subvolumes. Please make this feature=20
available to us, as its a "poor man's dedupe" and would give big space=20
savings for many use cases.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html