From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net Date: Tue, 17 Feb 2009 09:53:12 +0000 From: anooop.anooop@gmail.com Message-ID: <2c60577b-edf1-4f3c-bdd9-d8b1b2859a5b@x38g2000yqj.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: Subject: Re: [9fans] Regarding venti block size Topicbox-Message-UUID: a2d02800-ead4-11e9-9d60-3106f5b1d025 > i guess i'm not up to speed yet. what is the advantage > of supporting blocks of different sizes? > > - erik I am doing a part of a bigger project which involves splitting files into many pieces and storing them separately for security reasons. I thought of using each piece as a block of data to be stored on a venti server. But since the number of parts a file will be split into need to be constant the block size varies. But may be this is not the right way to do it. I am now re-considering splitting files into number of pieces = filesize/block size. > If you don't care > about coalescing duplicate blocks (and you > don't seem to), why not use an extent-based > file system instead? > > Russ It is necessary for me to avoid duplicate blocks and hence it doesnt look like other alternatives will work here. > maybe i'm being stupid, but isn't that precisely what the > vac format (as documented inhttp://www.cs.bell-labs.com/sys/doc/fossil.pdf) > and its block tree structure is there for? I have to learn more about vac before I say anything about this. I will get back after catching up. but what I understand is vac backs up file system trees on the server. I am on linux and using plan9port.And I am using raw partitions for arena, index and bloom filter and do not have a fossil fs. If vac can store a single file and retrieve it, then I will be able to use this to store the parts of the original file. I was using "venti/write -h 127.0.0.1 < datablock" to store file parts until I hit the upper limit when I started using "comparatively" bigger files which gave bigger than 64k parts. ~Anoop