Re: [PATCH] cowlinks v2
From: Eric W. Biederman
Date: Sat Mar 27 2004 - 16:05:04 EST
Jamie Lokier <jamie@xxxxxxxxxxxxx> writes:
> Eric W. Biederman wrote:
> > It is easy to add something like a cowstat or a readcowlink and teach
> > the few programs that care (i.e. diff, tar,...) how to use it. So I
> > would rather concentrate on making cow links look like a separate copy
> > than early optimizations.
> I agree, having each cowlink look like a separate copy, with separate
> inode numbers, is best. That _is_ POSIX compatible -- the sharing is
> just a storage optimisation, and programs which only use the POSIX API
> won't see the difference.
> I have no problem with adding cowstat() to diff, and I'm sure other
> people will eventually extend rsync and tar to use it, if it becomes
> widely used.
> It's not the simplest solution, though. The filesystem changes are
> non-trivial. (The simplest solution is just an ext2 attribute which
> says you can't write to the file if it has >1 links).
There are two possible implementations strategies for implementing
cow files. You can either start as Jörn did with hardlinks, or you
can start with symlinks.
The set of tradeoffs is interesting. When using hardlinks the only
sane thing to do is to change the inode number when you do a copy.
You are limited to normal files, no directories, no symlinks, and the
original must resided on the same filesystem as the copy. In addition
a copy will always have a link count of one. So on that score I
see a hard time getting POSIX semantics out of the a hard link based
When you start with symlinks the tradeoffs are different. You only
trigger a copy on write when you go through the copy not when you
write through the original. You get distinct inodes for free. They
can be straight forwardly extended to work on symlinks and other node
types. You can have multiple links at the end of the copy, because
symlinks can be hard linked. The original can be stored on another
filesystem. If you don't change the original you get POSIX semantics.
As for simplicity I think the two approaches are roughly equal.
As my memory has it the proto implementation I saw using a stackable
fs and cow symlinks was about a 1000 lines. And it was that large
because it was complete (i.e. it did the copies including copying
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/