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

> > Of course, it gets more interesting if you try to do it at the block
> > level instead of at the file level. For ext2, you could just reserve
> > a block #, say -1, to mean take the data from the master cow file, and
> > anything else is treated normally. You would need a deamon to make
> > sure you were still saving space though.
>
> More interesting is correct. I see the advantages and proposed this
> myself some time ago, but there are downsides. Basically, for each
> block you need additional data, at least a counter telling you the
> number of users it currently has. Eats up memory.
>
> If it really has to make sense, you also have to detect duplicated
> blocks at runtime. So you need a checksum for each block and a
> balanced tree containing those checksums or some other means of quick
> access. Eats up 40 bytes (16 checksum, 3*8 tree pointers). With 4k
> blocks, that's 1% memory overhead.

Well, you could do this in userspace, do it only if system is idle,
and use "scan" type approach.

But I agree that's far away.

BTW what about the "mix hardlinks with cowlinks" proposal? You said it
leads to hell and then I did not hear from you. Did it scare you that
much? ;-)
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.380 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site