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/