Re: [9fans] Regarding venti block size

[anooop.anooop@gmail.com]

> 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