lkml.org 
[lkml]   [2004]   [Mar]   [13]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
DateSat, 13 Mar 2004 22:03:05 +0100
FromPavel Machek <>
SubjectRe: [PATCH for testing] cow behaviour for hard links
On So 13-03-04 20:48:27, Jörn Engel wrote:
> On Sat, 13 March 2004 14:43:30 +0100, Pavel Machek wrote:
> > 
> > I do not know your current design, but...
> > 
> > In ideal world there would be no COW links. System would
> > magically detect that you are doing cp -a, and would link
> > at individual block level.
> >
> > Well, that would be probably too fs-specific. But introducing copyfile()
> > syscall, which would just link the inodes if underlying fs
> > supported it might be good start. On first
> > write into one
> > of linked files copy
> > would be done...
> 
> Agreed.
> 
> > Only disadvantage I see is that such links would not survive
> > tar-backup...
> 
> That's not a problem either.  Have a userspace program that checks all
> files and hints for identical ones (new syscall, copyfile() cannot do
> this without races).  Depending on fs size, the necessary data can
> grow into the gigabytes, but the code is just 200 lines.

Hmm, I don't quite like "copyfile if not modified" syscall, but even
without that it is usefull...

> Or did you mean the problem of tar backups growing *much* larger than
> the real filesystem?  Yes, tar becomes useless for backups then. :)

Yep, this is what I meant.
								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 13:01    [from the cache]
©2003-2008