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

From: Jörn Engel
Date: Fri Mar 12 2004 - 13:22:28 EST


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
-
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/