[RFC] vfs: Support for COW files in sys_open

[Carl Spalletta <cspalletta@gmail.com>]

I need a quick heads up on the following proposal regarding adding
support for COW files in sys_open.  The way it works is this:

A self described "COW-aware" application will open files with the proposed
O_COW flag to sys_open.  Getting back the proposed error value ECOW it
knows it has requested write permissions on a COW file (marked as such
by its owner with the proposed value S_COW) and it must preserve the
contents of the original file.

Applications can set their own policy on this:  For illustration,
one policy would be if the path given to open was a symlink it can
provisionally rename the link and open a new unlinked regular file with
the same contents.  If anything actually gets written it just closes the
regular file when it is done.  Otherwise it deletes the unchanged regular
file and moves back the symlink where it was.  If the path given to open
was a hard link it can do the same, moving aside the file and creating
a new unlinked file, treating them both with the same logic as in the
previous case.

There are probably many different policies that could be adopted, that
is not what I am arguing about.

The point is, this proposal is intended as a bridge to allow COW semantics
to be provided by applications until a final solution is agreed upon
in the kernel.  It could in some measure serve as a testbed  for that
hypothetical "final solution".  And files marked S_COW would remain so
even if this proposal was to be superseded by a kernel-only approach.

Applications would not need to be concerned with the different IOCTLs
and IOCTL args for each filesystem, or the status of individual
filesystems with regard to implementation of the proposed S_COW
flag. Just 'open("path",flag | O_COW)';  moreover nothing would be
broken either in userspace or the kernel since ECOW is never returned
from anything that does not end up passing a mask containing O_COW to
fs/namei.c::permission(); ie, only if an application or a kernel user
deliberately adds that flag to the mask.

Original patch here:

http://lkml.org/lkml/2006/6/8/213