On Wed, Dec 06, 2006 at 11:34:35AM -0500, Jan Harkes wrote:
> if the link happens to be between different volumes. If we combine that
> with content addressible storage for container files on both the server
> and the client, copies within the same volume only create a new vnode
> but use no extra disk space.

Actually, I just realized we already have a nicely working copy-on-write
mechanism that is used by backup and clone volumes which would work
perfectly for a copyfile() type operation and doesn't depend on adding
content addressible storage for container files (which could still be
interesting on it's own).

It is just that the COW container file functionality isn't exposed to
the clients, but is only used when we clone a volume. This idea may be
considerably easier to implement than I thought.

> Of course with a traditional UNIX hardlink we create multiple directory
> entries that point at the same object. If we use copies operations like
> chown, chmod, or truncate would only affect that one copy. But not

And of course write() to a 'hardlinked' file would effectively 'break
the link' as we wouldn't update all copies. So yeah, effectively we'd
have hardlinks with copy-on-write semantics. Like I said, I have a vague
idea that this may be useful, especially considering how limited our
current support is for hardlinks.

Jan