Re: [PATCH] cowlinks v2

[ebiederm@xmission.com (Eric W. Biederman)]

Jamie Lokier <jamie@shareable.org> writes:

> Eric W. Biederman wrote:
> > So I see a problem with Scenario C.   Perhaps you can refute it.
> 
> Ick.  You're right.  I cannot refute it.

The upside is since we can't it makes the implementation much easier :)
 
> Fwiw, I would have broken the directory cows on the first write, not
> the open.

I did it only so that programs do not see inode numbers change under
them.  For the copy that gets the original inode numbers delaying
until write is fine, for the copy with the new inode numbers to avoid
surprises you need to break the cow on the directory and move it to
the files on readdir, stat, and open.
 
> Thus, snapshots using lazy directory copies requires either that there
> are no hard links of the type you described (e.g. when snapshotting
> the root of the filesystem), or rather complex metadata to track the
> hard links, not dissimilar to the metadata needed to preserve hard
> links _within_ the snapshot.  They both seem far too complex to be worth it.

Agreed.
 
> Hard links just don't play well with lazy cowlinked directories.
>
> They are fine with non-lazy directory cowlinking, where the whole
> directory tree is duplicated and only files are cow'd.  Note that this
> doesn't apply to the original implementation which used hard links
> with a special flag: maintaining hard links in conjunction with
> cowlinks requires the inode duplication we've been talking about.

? The problem is lazy propagation of the cow flag.  The implementation
for ordinary files does not matter.  Only the implementation
for directories matters.
 
> Btw, if we have cowlinks implemented using inode duplication, then it
> isn't necessary for both inodes to have the same metadata such as
> mtime, ctime, mode etc.  Only the data is shared.  That means the
> sendfile() system call could conceivably be overloaded, meaning to
> copy the data, and let "cp --cow" decide whether it wants to copy the
> metadata (same as as "cp -rp" or "cp -rpd"), or not (same as "cp -r").

Sendfile feels about right but it has a few issues that complication
something like this.  It works on file descriptors, and it takes
a length parameter.

There is a lot of room for things to go wrong when implementing
cowlink(const char *oldname, const char *newname) in user space.

Since the semantics are a delayed sendfile in other ways sendfile
feels like a good fit.

Eric