monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] reiser for monotone?


From: Nathaniel Smith
Subject: Re: [Monotone-devel] reiser for monotone?
Date: Tue, 7 Feb 2006 17:11:05 -0800
User-agent: Mutt/1.5.11

On Tue, Feb 07, 2006 at 04:43:14PM -0500, address@hidden wrote:
> I've been looking at the reiser file system documentation recently, and 
> in particular, reiser4.  It seems that they have implemented an 
> object-oriented-like object store, with types and methods, and so forth, 
> and then built the Linux reiser4 file system on top of that.  It appears 
> to be amazingly efficient, especially for large numbers of small files, 
> and is able to guarantee atomicity of transactions for data (instead of 
> just metadata, as reiser 3 did).  It makes me wonder whether it would be 
> better to implement something like monotone on top of reiser4 instead of 
> SQLite.  I get the feeling it's good for systems that like to keep 
> complicated data structures on persistent storage.

Sqlite changed the world not because it did something no-one else did,
but because it packaged it up differently -- there are lots of
systems dealing with data storage, transactions, structured queries,
etc., but it wins by combining power with convenience, lack of
impedence, and other such fuzzy-but-critical things.

VCSes live and die by integration.  As cool as reiser may be, I just
can't see how we can tell a compelling story for people on win32,
people on OS X, people on *BSD, people who like ext3 and don't trust
reiser yet, people who want to zip up a db and put it on their web
site, people who want their standard backup tools to work...

Even if one could extract from the reiser code a portable user-level
library that let you use the cool features against regular files
(partitions are just big files, after all), I'm _guessing_ it wouldn't
be so useful, because filesystems all assume that they have a fixed
size arena to play in, while monotone wants to always grow its repo
exactly as much as necessary, but no more.  (This is actually why disk
locality stuff is hard.  If we could just scatter big chunks of empty
space through the db, life would be much easier :-).  Traditional
filesystems are allowed to do exactly that...)

-- Nathaniel

-- 
Sentience can be such a burden.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]