Messages in this thread | | | Subject | [RFC] vfs: Support for COW files in sys_open | Date | Mon, 12 Jun 2006 14:10:25 -0400 (EDT) | From | Carl Spalletta <> |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |