Mini-Conference Proposal: olpcfs

[Tomeu Vizoso]

On Mon, Mar 24, 2008 at 5:35 PM, C. Scott Ananian <cscott at laptop.org> wrote:
> 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.

Sure, I was asking you to extend your self a bit on that.

>  > 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.

Of course it is an implementation detail, but one that is a major
roadblock in the effort to implement the specified design.

>  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.

Thanks.

>  >  - 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.

I was talking here about the other way, checking in files into the DS:
during a Write session, what needs to do the activity in order to get
a new version every time after the user clicks on the Keep button?
Just close the file and open it again?

In most cases, every time an activity saves the current state several
files plus their metadata will be updated, can that happen atomically?

>  >  - 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.

I was just stating my motivations for wanting to replace the existing
DS, nothing directly related to olpcfs.

We do have performance problems with the current DS, even with
relatively few entries.

Tomeu