Re: [RFC] The reflink(2) system call v4.

[jim owens <jowens@hp.com>]

Sage Weil wrote:
> Maybe not, but that's a separate question from the interface issue.  We 
> shouldn't preclude the possibility creating tools that preserve attributes 
> (or warn if they can't) and tools that simply want to cow data to a new 
> file.  AFAICS reflink(2) as proposed doesn't quite let you do either one 
> without extra hackery to compensate for its dual-mode behavior. If this 
> thread has demonstrated anything, it's that some users want snapshot-like 
> semantics (cp -p) and some want cowfile()-like semantics (cp).  What is 
> the benefit of combining the two into a single call?  If I want 
> snapshot-like semantics, I would rather get -EPERM if I lack the necessary 
> permissions than silently get an approximation.

I'm not fighting against two syscalls but the reason I like
the V4 definition is the opposite of knowing I failed to snapshot.

It is really because in my experience as both root on multi-user
systems and basic untrusted user, when root copies something from
a user there are only two desired outcomes:

  1) cp -p

  2) cp, chown "someone" , chgrp "somegroup", chmod "new rights"

The common mistake is wanting #1 and forgetting the -p so it
then produces an error and has to be fixed.

Using root's default attributes is almost never desired.

So with this reflink() definition, normal users get their own
attributes and root automatically gets preserve but can change
them later.

IMO this is optimized for humans, and I don't really know
of any privileged daemon things that are setuid and
want to not preserve attributes.  Do you have examples?

jim