Re: [PATCH 1/3] fs: Document the reflink(2) system call.

[Andreas Dilger <adilger@sun.com>]

On May 05, 2009  00:16 -0700, Joel Becker wrote:
> On Tue, May 05, 2009 at 02:07:03AM +0100, Jamie Lokier wrote:
> > Being able to have different attributes would allow:
> > 
> >    - reflink() to be used for fast space-efficient copying, i.e. an
> >      optimisation to "cp", "git checkout" and things like that.
> 
> 	It can right now, just not of other people's files.  Actually,
> the only real difficult with doing it to other people's files is quota.
> But I can't come up with a way to prevent quota DoS.

If the reflink caller is always charged for the full space used (as if
it were a real copy) by virtue of the user doing the reflink() owning the
new inode.  Doing anything else seems broken.  If the owner of the file
wasn't charged for the reflink's quota then if the reflink inode was
chowned the new owner would be charged for the new file, but the quota
code would have to special case the decrement of EACH of the reflink's
blocks because otherwise the original owner might "release" quota that
it was never originally charged.

> 	Here's another fun trick.  Overwriting rsync, instead of copying
> blocks from the already-existing source could reflink the source to the
> .temporary, then only write the changed blocks.  And since you own both
> files, it just works.  If you're overwriting someone else's file?  The
> old copy behavior is fine.

Well, "fine" as in it works, but if there are only a few changed blocks,
and the old copy is now part of a snapshot (so it won't be released when
rsync is finished) the space consumption has doubled instead of just
using a few extra blocks.

> > Requiring all attributes except nlink and ino to be identical makes
> > reflink() unsuitable for transparently doing those things, except in
> > cases where they happen to have the same attributes anyway.
>
>        We've had a lot of fun thinking up many uses for reflink(), and
>	almost all of them are within the context of one's own files.

Is there anything about changing the owner/group of the new inode during
reflink that makes the implementation more complex?  If the process doing
the reflink is the same as the file owner then the semantics are unchanged
from what you have proposed.

> > I'm thinking particularly of file permissions, owner/group and atime.
> 
> 	People do cp -p all the time.  I don't see how keeping those
> things the same will break anything.  It's a new call, not an existing
> semantic.

Though "cp -p" doesn't keep the owner/group of the original file if you
are not root.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.