Mini-Conference Proposal: olpcfs

[Martin Langhoff]

On Fri, Mar 21, 2008 at 12:53 PM, C. Scott Ananian <cscott at laptop.org> wrote:
>  More information: (draft) http://wiki.laptop.org/go/Olpcfs

The thinking behind this is *excellent*.

If we make a couple of minor tweaks and we take that as the
description of the goals, then we can implement that, and a ton more
in a couple of days by using real files in the filesystem, a single
file containing the "fancy" metadata, and committing things into GIT.
Which gets us to the place where we want to be, with 100th the
engineering effort.

The API gets simplified to:

 - a convention of the fact that for each "document" you are given a
directory - which will get shown as a single item in the UI, a la OSX
with .app bundles

 - in that directory, an optional metadata.yaml (or .xml or whatever)
holds additional metadata.

 - the application can make a "save snapshot" call to trigger a commit
(mapped to the "save document") but this is optional because...

 - when the app exits with a 0 the files get committed

 - when the app exits >0 the files get committed in a specially tagged
commit that indicates abnormal termination - so the journal may later
offer to attempt to open that set of files

 - we can use a readonly FUSE view of the repo or just plain git from
journal to retrieve old version -- but any file retrieved to work on
gets extracted to the real FS

That's the "pragmatic pseudo-API". Some technical notes...

 - by virtue of always working with a real FS, we can direct app
developers to use mmap and similar advanced tricks to work efficiently
on data. Supporting mmap is hell if we do our own FUSE implementation,
and we _need_ performance tricks like mmap.

 - by virtue of using a normal FS, it works with tar, zip, rsync,etc.
Every OS that has extended the POSIX basics has had to come up with
its own archiver implementation to handle the extensions (hi Darwin!)

 - the work of the School server with backups is _trivial_ ;-) -- git push

 - it is trivial to implement a "sliding window" to "forget" old
commits as the disk gets full, and a longer sliding window on the XS

 - we can tweak our git configuration to work well with the Flash and
jj2fs filesystem

A few advanced tricks will need some tweaking (handling low disk
conditions until we can consolidate packs, packing opportunistically
when we have a power source), but by avoiding the FUSE path we can
save a ton of time which we can use for those purposes.

And then, with the experience of doing this the cheap way, we can
schedule a year or two to write a new FS, and have a go at nailing a
better implementation than Torvalds and his ragtag band of kernel
developers ;-)

cheers,



martin
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff