Re: [PATCH] cowlinks v2

[Pavel Machek]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/