> 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
