From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii; format=flowed Mime-Version: 1.0 (Apple Message framework v1076) From: Eric Van Hensbergen In-Reply-To: <4ADDB2D7.3020606@metux.de> Date: Tue, 20 Oct 2009 08:39:03 -0500 Content-Transfer-Encoding: 7bit Message-Id: <0642F742-829D-41C0-BE35-A4E8FEA49224@gmail.com> References: <13426df10910152032rf542759mb53b4518491b0244@mail.gmail.com> <4ADDB2D7.3020606@metux.de> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] Venti over DHT Topicbox-Message-UUID: 8c47ca92-ead5-11e9-9d60-3106f5b1d025 On Oct 20, 2009, at 7:53 AM, Enrico Weigelt wrote: > > I've also done some bits of works in that area > (nothing usable yet ;-o), but with different > requirements: > > * storage near to the user (at least local mirrors) > * equal data should get equal score (even w/ encryption) > * automatic removal of stale blocks -> garbage collection > * efficient also on small data blocks > > Especially the distributed GC together w/ encryption turned out > not be quite trivial ;-o > On the one hand we need things like timestamps, on the other hand > we need to trace the tree structures w/o decryption. > > So I added several block types: eg. blob (payload data) and inode > (holding the tree). blobs are encrypted w/ their score, thus > reading takes scores (outer for retrieval, inner for decryption). > inodes have an public area, listing just the outer scores and an > encrypted one holding the inner scores. The tree formed by inodes > doesn't necessarily has to be fully balanced, so incremental writes > with special heuristics for preventing unncessary writes are possible. > > > If someone likes to hear more about this, just let me know :) > I'm interested. Particularly in the multi-layer caching/mirroring and the encryption/same-score details. -eric