lkml.org 
[lkml]   [2004]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] cowlinks v2
Hi!

> > Okay, now I have to start talking about implementation. Assume ext2 as
> > a base. Theres new object "cowid" which contains, well, id for
> > get_data_id() and usage count. Each inode either has pointer to
> > "cowid" object, or it is plain old regular file.
>
> Pavel has it exactly right.
>
> A simple way to store COWID objects in the filesystem itself is as
> another ordinary inode. The attributes of that inode (mtime, mode
> etc.) aren't important (except to fsck), only the size and data
> pointers are important. The files which point to a COWID need a flag
> to indicate that, too.

Actually, my solution has one weirdness...

> a
copyfile a b
rm a

...now b has pointer to cowid with usage count of 1. Which is slightly
ugly (and wastes one cowid entry), but should be harmless.

> get_data_id() is one way to detect equivalent files. Another would be
> a function files_equal(fd1, fd2) which returns a boolean.

files_equal(...) would lead to quadratic number of calls, no?

> get_data_id() has the advantage that it can report immediately whether
> a file has _any_ cowlink peers, which is important for programs that
> scan trees. Perhaps getxattr() would be reasonable interface, using a
> named attribute "data-id".

Yes, get_data_id() is extremely ugly name.
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/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.157 / U:0.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site