Messages in this thread | | | Date | Tue, 30 Mar 2004 01:16:35 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH] cowlinks v2 |
| |
Hi!
> > > > What happens if the disk fills while you are making the copy? Will > > > > open(2) on an *existing file* then return ENOSPC? > > > > Applications can not be sure that it is existing file. If you > > do stat followed by open, someone may have removed the file in > > between. So it is not so new case. > > I should have said, "Will open(2) without O_CREAT then return ENOSPC?" > > This is definitely a new case. > > For what it's worth, I agree with whoever (Jamie?) said that COW > should be primarily a space optimization, and that semantically the > two files should mostly behave like separate copies. > > In fact, I think it is unfortunate, in some ways, that things like > permissions and timestamps are kept in the inode. This means that two > files may only be COW-linked if they also share ownership, > permissions, and timestamps, which makes COW links less useful for > some applications (e.g., sharing source trees among multiple > developers).
I think they *should* have separate permissions.
Also it should be possible to have file with 2 hardlinks cowlinked somewhere, and possibly make more hardlinks of that one... Having pointer to another inode in place where direct block pointers normally are should be enough (thinking ext2 here).
> But sharing data blocks without sharing inodes is too horrible even to > contemplate, I suppose.
Why, btw?
Lets say we allocate 4 bits instead of one for block bitmap. Count "15" is special, now it means "15 or higher". That means we have to "garbage-collect" to free space that used to have more than 15 links, but that should not happen too often... Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?]
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |