Mini-Conference Proposal: olpcfs

[C. Scott Ananian]

On Sun, Mar 23, 2008 at 12:20 PM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>  - Do you think that the POSIX API is very much tied to the underlying
>  implementation or should be discussed separately?

I have at least three different implementation ideas.  I plan to use
FUSE for the "crappy first draft" implementation; it may turn out that
the crappy first draft is actually good enough for real use, but there
are certainly lots of other alernatives, both for flash and for
disk-based filesystems.  Martin seems to be arguing for using git
under the covers; that's a fine implementation.

>  - This POSIX API would be the main way to access the data? Or just one
>  more way? If so, have you already thought about the main API? Anything
>  better than D-Bus?

The POSIX API should be the main way to access the data.  Complex
compound queries may be more efficient if they use a special-purpose
API, and there might be special hooks for the garbage-collector and
maybe import/export tools, but fundamentally data store objects should
be "just" files.

>  In general, I would like to know first more details about your
>  motivations for redesigning the DS.

I outlined these at the top of the olpcfs wiki page.

> Mine are the following:
>  - add versioned entries and delta-based storage,

Delta-based storage is an implementation detail, certainly possible (I
provided cites in the olpcfs page for how it would be done).  I don't
think it should be a visible part of the API.

Versioning is definitely a motivation; the Journal might add extra
versioning metadata to account for non-local versions; I'll try to
find time to write that up more explicitly.

>  - get a saner way of passing files from activity side to the DS-managed side,

My answer here: they are just files.  All existing applications can
open files, given a path.

>  - make it more maintainable, perhaps add one lawyer of abstraction so
>  we can switch later to a different full text engine, metadata storage,
>  etc,

The proposed "olpcfs" is exactly the "layer of abstraction".  Lots of
different implementations under the hood of the proposed API are
possible.

>  - increase scalability and raw performance.

Not sure exactly what you mean here, but these seem to be
implementation issues, not API issues.  Unless you think that some of
the proposed APIs are impossible to implement efficiently?  Our
existing Sugar activities don't heavily exercise the filesystem, so I
think that raw performance is not an important metric for our first
implementations.  I'm much more concerned with the transparency and
interoperability of the API.
 --scott

-- 
 ( http://cscott.net/ )