Messages in this thread |  | | | Date | Thu, 16 Oct 2003 21:19:27 -0400 | | From | Jeff Garzik <> | | Subject | Re: Transparent compression in the FS |
| |
jw schultz wrote: >>Consider a simple key-value map, where "$hash $n" is the key and the >>value is the block of data. Only three operations need occur: >>* if hash exists (highly unlikely!), read and compare w/ raw data >>* write new block to disk >>* add single datum to key-value index > > > Nicely described, but each block now needs a reference count > which is incrmented if the raw compare yields a positive and > decremented when a reference to it receives a write.
Yep. I'm pondering a sort of a closely-interconnected distributed cache for archival storage, so I have to care about refcounts on remote servers, too.
> It may help to also have a reverse reference somewhere > from the block to the hash.
I think I can avoid this...
>>Inode block lists would need to be updated regardless of any collision; >>that would be a standard and required part of any VFS interaction. And > > > Under current schemes if i overwrite an already allocated > block of a file the block list need not be updated unless > the block is relocated. But that is a nit.
Yep. For a networked filesystem, this is less annoying and clients will not normally notice any slowdown from this.
Jeff
- 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/
|  |