Roman Shaposhnik wrote: > On Tue, Oct 20, 2009 at 8:53 PM, Enrico Weigelt <weig...@metux.de> wrote: >> So I added several block types: eg. blob (payload data) and inode >> (holding the tree). > >>From these I infer that you've build an object store, not just a block sotre. > How close was it to this: > http://oceanstore.cs.berkeley.edu/publications/papers/pdf/asplos00.pdf
Not really, NB is somewhere in the middle between venti and O.S. The actual storage system is quite dumb: it knows nothing about file/object lookups, routing, replicas or updates. All it does is just storing several types of blocks and collects some bits of statistical data. When a requested block is not found locally, it simply asks it's neighbors. Retrieved blocks are stored locally for a while (until GC catches them up). Inode blocks are nothing more than score lists, which holds a bunch of data blocks (belonging to some bigger entity, eg. file) together, so GC operate on that higher layer and doesnt have to look at each single block (which even might not be present locally). Each node keeps track of the inodes which it's interested in (eg. has a local client or a friend neighbour node operating on them). Here we collect things like TTLs, usage patterns, etc. Compare it a bit to GIT: * data blocks = blobs * inodes = commits * inode-refs = commit-refs Local GC goes like this: 1. purge old inode-refs (eg. long-unused) 2. purge unref'ed inodes 3. purge unref'ed blobs To stop GC from removing some inode: simply "touch" it (add it to reflist / update atime in reflist). To stop GC from removing data blocks: simply create a inode referencing them. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: i...@metux.de skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------
