From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: plugins - examples and (more) docs Date: Thu, 30 Sep 2004 10:52:35 -0700 Message-ID: <415C47E3.9010703@namesys.com> References: <41556502.6030505@desy.de> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <41556502.6030505@desy.de> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Martin.Gasthuber@desy.de Cc: Reiserfs-List@namesys.com Martin Gasthuber wrote: > Hi, > > for our large storage system holding half a petabyte of experimental > physics data, we are looking for a new nameservice implementation. > Roughly this means - just store filenames in a hierarchical fashion > (as usual) but only store metadata (from the other storage system > components i.g. disk-cache and tape store) and no real data (this is > in the cache - one or more times, and the 'real' copy is on tape). > Right now we have a DB (simple key/value) system with a faked NFS > server code on top. > While looking at other ways and making proof of concept implementation > i 'traped' into reiser4 with the important plugin feature. For our > system we need 'unique + persistent' IDs for files with the ability to > map in both directions (name -> id, id -> name), extended attributes > and virtual files. From what i understand, reading the reiser4 docs > i've found, all this should be feasible by creating new plugins for > files and IDs. Because i like 'real' stuff - im' looking for plugin > example code and more docs related to plugin creation and integration. > Any idea where i can find that ??? > > Regards, > Martin > > You are right that this is doable, for examples see our source code which is much better commented than the rest of the kernel (disclaimer: akpm code is better commented than ours).