Re: [PATCH] cowlinks v2

From: Eric W. Biederman
Date: Thu Mar 25 2004 - 16:48:29 EST

Jamie Lokier <jamie@xxxxxxxxxxxxx> writes:

> Eric W. Biederman wrote:
> > 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.
> That is not useful for me or the other people who want to use this to
> duplicate large source trees and run "diff" between trees.
> "diff" depends on being able to check if files in the two trees are
> identical -- by checking whether the inode number and device (and
> maybe other stat data) are identical. This allows "diff -ur" between
> two cloned trees the size of linux to be quite fast. Without that
> optimisation, it's very slow indeed.

In the case where cow is implemented as a stackable filesystem it is
easy to discover the changes by looking at the underlying fs instead
of at the cow view. If the file was not changed the file was not

The reason for the late copy is some programs open files O_RDRW and
only read the file. If those triggered a copy on write when you
opened the file, diff would still need to go to the work of manually
comparing the files.

The underlying idea of copy on write is that you have separate files
that happen to be storing the same data, in the same space. Anytime
you deviate from that is when you are going to get surprised.

The case I care about is sharing the same root filesystem on different
machines, and that must look like 2 separate filesystems.

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at