Re: [PATCH for testing] cow behaviour for hard links

["Jörn Engel" <joern@wohnheim.fh-wedel.de>]

On Fri, 12 March 2004 18:48:57 +0100, Sytse Wielinga wrote:
> 
> I'm sorry to say this, but I stumbled upon a prohibitive problem...
> 
> The problem is that if a hard link would be broken up, one of the dentry's 
> would get a link to a new inode with a new inode number. This would mean that 
> right under the nose of the app, the file suddenly gets a new inode number. 
> Apps don't like that. If anyone has any suggestion that might make this 
> possible please say so, but I don't see it.

Different design.  How about this:
- Files with just one link remain as-is.
- Linking a file:
  - Create a new inode and move all data into new inode.
  - Make old inode a pointer to new inode.
  - Create a second pointer to new inode.
- Unlinking a file:
  - Unlink pointer inode
  - Unlink target inode
- Writing to a pointer inode:
  - Make pointer inode a regular one.
  - Copy target inode data into former pointer inode.
  - Unlink target inode
  - If target count was 1, we don't even need to copy.

Or in ascii art:

Regular file:

	inode 1

Second link:

	inode 1 ---> inode 2
	             ^
	inode 3 -----|

Write to inode 1:

	inode 1

	inode 3 ---> inode 2

Unlink of inode 3:

	inode 1


Not quite as simple and straightforward as my first design, but it has
some advantages.  Would even be possible to extend it and allow links
across different filesystems.

Jörn

-- 
A quarrel is quickly settled when deserted by one party; there is
no battle unless there be two.
-- Seneca