[prev in list] [next in list] [prev in thread] [next in thread] 

List:       reiserfs-devel
Subject:    (reiserfs) Re: Adapt FS to run in user mode
From:       root <reiser () idiom ! com>
Date:       1999-05-30 17:38:52
[Download RAW message or body]


Reiserfs is intended to become a naming system, not just a traditional
FS.  It should allow you to use it as just an object store.  We will
modify reiserfs to allow applications to manage keys, and to allow you
to access objects which might have 0 names but a positive link count, it
is just a matter of time.

Hans

Scott A Crosby writes:
 > On Wed, 26 May 1999, root wrote:
 > 
 > > Kevin Littlejohn writes:
 > >  > >>> loic@ceic.com wrote
 > >  > > Kevin Littlejohn writes:
 > >  > >  :-) We have three major issues in the balance:
 > >  > > 
 > >  > >  a) Efficient disk storage management
 > >  > >  b) Custom needs of an application (squid, full text indexing for instance)
 > >  > >  c) Portability
 > >  > > 
 > >  > >  Your choice is to implement a) according to b) in such a way that c) is
 > >  > > not a problem. 
 > >  > 
 > >  > Sorta.  a) is a function of b) - efficiency really needs to be measured
 > >  > in terms of the application in question.
 > >  > 
 > 
 > Applications need two things: object store, and object-store management.. 
 > 
 > The object store allocation requests (with locality information), and
 > returns a key to access that object. 
 > 
 > For things like databases, squid, news, and so on, this is most of the
 > functionality that is needed. 
 > 
 > Let reiserfs just implement tho object store.
 > 
 > The second part is the object-store managment, the thing that offers an
 > organization to the object store.. This could be the heirarchial
 > filesystem code, in the kernel, or an application-managed dictionary (in
 > squid or news servers) or something more sophisticated. 
 > 
 > This also seperates the functionality of the object store and the
 > object-management (filesystem), so that one can add in additional
 > object-management features (ACL's, additional metadata, etc) without
 > modification to the object-store code.
 > 
 > There will likely be more ineffeciency for general use because of the
 > layering, and that the object-store doesn't understand the
 > object-managment metadata. But it also has more flexibility,
 > application-specific 'filesystems/object-managers' can be directly built
 > easily from user-space and tied to the most efficient object-store
 > interface. (a balanced tree object-store for normal use and small objects,
 > an extents-based one for large multimedia files, a block-based one for
 > other purposes, etc...)
 > 
 > Finally, the object-store abstraction has possibilities in terms of volume
 > managment. Objects of a certain type can have different volume-management
 > properties in terms of RAIDing or mirroring. 
 > 
 > 
 > Rumor has it that a future SCSI will offer a mode that exports an
 > object-store interface.
 > 
 > 
 > >  > >  My opinion is that implementing a) is a *very* difficult task. The
 > >  > > huge amount of knowledge and time Remy Card (ext2fs) and Hans Reiser
 > >  > > (reiserfs) spent on this problem show this. Assuming this, it seems easier
 > >  > 
 > >  > True, however they were attacking the problem of _generic_ filesystems.
 > >  > I understand reiserfs is a damn good fs - it's been thrown around a few
 > >  > times as a good solution for squid - but it's efficiency as a generic
 > >  > filesystem is better than it's efficiency as a specific-purpose fs.
 > >  > 
 > >  > That's why inn has it's own little cyclic thing - because it suits the
 > >  > 'news' way of doing things.
 > >  > 
 > >  > Specific example, in squidfs, you'll notice there's no such thing as ls -
 > >  > because there's no such thing as a directory structure.  Why support such a
 > >  > thing (with associated update costs), when you can throw away most of that
 > >  > information and still maintain enough for squid to work with?
 > > 
 > 
 > ResierFS is a damn good object-store. Why prematurely saddle it with all
 > the problems of an FS, when there are already many tasks that only want
 > an object store? 
 > 
 > Scott
 > 

[prev in list] [next in list] [prev in thread] [next in thread]