Not surprising that the discussion is all over the place
as far as what this should do. Whether is is better to
implement one do many things syscall or several different
syscalls for different features can be debated after we
set some rules. Going back to Joel's patch, I think the
first rules we need agreement on are:
1) is only for filesystems with COW operation,
if the fs does not support COW it returns ENOSYS.
the rational is that while we could allow it to
be a copyfile, it would not save space so "cp -a".
2) is only for regular files, all others return EPERM
*note* as-coded the patch only traps S_ISDIR, but
other file types could be a problem on some fs and
I don't see any value in supporting more than regular
files unless we support directory COW and then we are
really jumping into the swamp.
3) the granularity of the COW (1-byte write may cause
1-block up through whole file copy) is fs-dependent.
4) post-reflink changes done to data or attributes
in either the original or new file are independent.
next rules if we assume reflink(2) matches Joel's
manpage and call arguments and any other features are
a different api definition:
5) you must be the file owner or have CAP_FCHOWN
because...
6) all non-time file attributes (owner, security, etc),
atime, and mtime match the original file. ctime is
when the reflink was created.
but the hard part is the quota accounting rule:
7) pre-charge all quotas so a reflink double-counts inodes
and blocks against the original owner/group
pro - easiest, does not allow owner to bypass limits,
quota utilities just work
con - admin snapshot can trip user quota-limit failures,
du/df will wildly disagree on space used
so is that what we want or do we want to just say the
behavior is fs-specific with respect to quotas.
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
