9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Enrico Weigelt <weigelt@metux.de>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Venti over DHT
Date: Thu, 29 Oct 2009 20:13:37 +0100	[thread overview]
Message-ID: <4AE9E961.3020602@metux.de> (raw)
In-Reply-To: <e763acc10910210453i7ab06d9cqaca19d38b703f844@mail.gmail.com>

Roman Shaposhnik wrote:
> On Tue, Oct 20, 2009 at 8:53 PM, Enrico Weigelt <weigelt@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: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------



      reply	other threads:[~2009-10-29 19:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-13 17:55 Roman Shaposhnik
2009-10-14  1:20 ` Russ Cox
     [not found]   ` <e763acc10910132148qbfd3a07q60d268a02d66c04e@mail.gmail.com>
2009-10-15 15:52     ` Roman Shaposhnik
2009-10-16  3:32       ` ron minnich
2009-10-16  4:03         ` Russ Cox
2009-10-20 12:53           ` Enrico Weigelt
2009-10-20 13:39             ` Eric Van Hensbergen
2009-10-21 11:53             ` Roman Shaposhnik
2009-10-29 19:13               ` Enrico Weigelt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AE9E961.3020602@metux.de \
    --to=weigelt@metux.de \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).