Re: [PATCH] cowlinks v2

[Eric W. Biederman]

Jamie Lokier <jamie@xxxxxxxxxxxxx> writes:

> Eric W. Biederman wrote:
> > Actually there is...  You don't do the copy until an actual write occurs.
> > Some files are opened read/write when there is simply the chance they might
> > be written to so delaying the copy is generally a win.
> 
> Programs depend on the inode number returned by fstat() not changing,
> and maybe in some other circumstances, even if they subsequently write
> to the file.
> 
> (It's ok for open() to change the inode number, because that's
> equivalent to another program changing the filesystem in parallel).
> 
> How do you handle that if COW occurs later than open()?
> You could also force COW when fstat() is called, I suppose.

One of the rougher patches, in that we don't have persistent inode
numbers.  Basically the two files never have the same inode number.
To the user they are always presented as two separate files.
Currently I believe the strategy is to assign an inode when the file
is read into the icache/dcache.  I think it is just a sequential
counter.

This was all implemented as a stackable filesystem.  Something
that gets down to the real filesystem could likely just reuse
the inode number of the cow link.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/