From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 8 Mar 2008 10:37:06 +0100 From: Enrico Weigelt To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] thoughs about venti+fossil Message-ID: <20080308093705.GB1386@nibiru.local> References: <14ec7b180803052015k6957e809p7c58dfa03545e026@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Topicbox-Message-UUID: 73b65f90-ead3-11e9-9d60-3106f5b1d025 * Wilhelm B. Kloke wrote: > After this fact the colliding block is itself very interesting, > aand it is also very likely that theis block will be stored and > archived just for this reason. Which will increase the chance of a failure ;-O > In practice though, a filesystem relying on venti could just > change the block boundaries for this case or choose some other > escape from needing to store these special blocks. hmm, let's assume, the scientists will come up with (maybe artificially constructed) collissions long before they'll happen in practice, we could handle them specially. All we need to do is to leave enough room in the keyspace, so we can assign them to these special blocks, once they've been discovered. A simple way could simply be an additional bit, which tells us that the key isn't the data's hash, but an explicitly assigned dictionary entry. Maybe a more sophisticated approach: add an keytype prefix, which allows dropping in several types of keys. Default might be sha-1, but for special cases another keytype (eg. "dict") can be used. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------