Messages in this thread | | | Date | Mon, 5 Apr 2004 10:19:08 +0200 | From | Pavel Machek <> | Subject | Re: [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/
| |