Re: [ANNOUNCEMENT PATCH COW] proof of concept impementation of cowlinks

[Pavel Machek]

Hi!

> > > That is probably unfixable now, but you can avoid making similar
> > > error. Provide is_cowlinked(fd1,fd2) syscall. Pity you will
> > > have to use different inode numbers for cowlinks (due to tar/cp),
> > > and this won't fly:
> >
> > is_cowlinked does not fly, either. For n files, you have to do O(n^2)
> > calls to find those that are linked.
> 
> Hm, let me think about it. diff does not need to check all permutations,
> it checks only those two which it needs to compare.

And tar?

> IMHO "inodes done right" is something like this: if inode numbers are
> different, then files are not hardlinked/cowlinked. If they are the same,
> check is_hardlinked(a,b) or is_cowlinked(a,b) to find out.
> 
> This beats O(n^2) argument.
> 
> But this is non-POSIX, would not be accepted.

I do not see how this matters. cowlinks are already non-POSIX. If
is_hardlinked() always returns 1, but is_cowlinked() sometimes returns
something else, you are still "as much POSIX as possible".

> I don't know how to handle this now. Introducing cow-inode number
> with semantic "cowino1==cowino2 => files are cowlinked" is
> ugly and won't deal with per-block cow. Sooner or later someone
> will want to have per block cow. Think about cow'ing multi-gigabyte
> database files for checkpointing/backup purposes...

Well, if only block 17 is cowlink-shared between two files, I guess
userspace does not want to know... And I think that cow-inode number
*can* handle all other cases.

Oh, get_cow_inode() should really be allowed to fail in some usefull
way, so that filesystems do not have to implement it if its hard for
them.

> > You want get_cowlinked_id which can return -1 "I do not know".
> 
> Is this the same to my "cow-inode number" concept above?

Yes.

-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.
-
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/