Re: [PATCH] cowlinks v2

[Pavel Machek <pavel@ucw.cz>]

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?]