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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
