Mini-Conference Proposal: olpcfs
C. Scott Ananian
cscott at laptop.org
Wed Apr 2 13:42:06 EDT 2008
On Tue, Mar 25, 2008 at 11:44 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> On Mon, Mar 24, 2008 at 5:35 PM, C. Scott Ananian <cscott at laptop.org> wrote:
> > 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.
The olpcfs design envisions a user-space process to do garbage
collection of old versions; it's not hard to do delta-compression in
userspace. xdelta and bsdiff do a fine job. To transparently
uncompress when the old version is accessed is only a little more
difficult, you just link to libxdelta2.
> > > - 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?
Well, it's certainly *possible* in the current implementation, but I'm
wary of promising too much. POSIX generally doesn't provide
multi-file atomic update. Amino
ACID transactions to POSIX-land via some heuristics (treat all
operations by this application as atomic, etc), but I'm not convinced
yet that this is necessary. Can you provide some specific use
( http://cscott.net/ )
More information about the Devel