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

[jim owens <jowens@hp.com>]

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