Mini-Conference Proposal: olpcfs
tomeu at tomeuvizoso.net
Thu Apr 3 12:49:08 EDT 2008
On Wed, Apr 2, 2008 at 7:42 PM, C. Scott Ananian <cscott at laptop.org> wrote:
> 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
> (http://www.fsl.cs.sunysb.edu/docs/amino-phdthesis/amino.ps) extended
> 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
I guess we only need metadata updates to be atomic. I'm thinking
specifically on the journal, as it displays the entries depending on
the metadata, would be good if the journal only tried to refresh its
display when the update has finished.
More information about the Devel