[Sugar-devel] [PATCH] Journal Volumes Backup and Restore

[Sascha Silbe]

Excerpts from Bernie Innocenti's message of Wed Jun 30 03:24:09 +0000 2010:

[Current patch has destructive restore]
> > One of the key design concerns in Sugar is that operations should not
> > be destructive. You can imagine how a "dangerous" button, made so
> > easily available, can be... well... dangerous.
> 
> I agree on this. What could we do in max. 1 day of work to mitigate this
> problem without giving up the backup restore functionality?
I have a working prototype for high-level backups using multi-entry JEBs (Journal Entry Bundles). You could take my code [2,3] as a "backend" for your UI code. That would combine the advantages of both approaches and should be doable in a day.

> NOTE: If users don't click it and they don't have enough space, their
> filesystem will fill up and Sugar will misbehave until rebooted. On the
> next boot, the diskspacerecover script will run, killing a bunch of
> activities.
Ouch. We should rather try to avoid getting into this situation at all. I thought the "Journal full" alert is meant to address (a part of) that?
It would probably make sense to make the data store refuse to store entries if there's less than a certain amount of permanent storage (10 MB?) available.
Quota support in Rainbow would be useful as well.

> NOTE^3: kids and teachers often ask: "how do I erase my journal?". It
> seems that sometimes the journal deletes itself spontaneously (on both
> 0.82 and 0.84),
Is there any way we can diagnose those cases? A full disk image available to individual developers under NDA (for privacy/confidentiality)?

> but users still cannot deliberately erase their journal.
I consider it a feature that erasing the entire data store requires a shell command.
If there's a school server available, give the Data Manager activity [1] a try. From the description:

The user can choose which documents to keep local and which to keep only on the schoolserver.

Instead of eradicating all their Journal entries, users could move them to the school server. That way they gain space on the local machine, but can still access their old work.
Adding a size column (including sort support) to this activity would make it even more useful, and I would consider it a better place for that feature than the Journal.

> "Why is this needed?" Because jffs2 starts slowing down and misbehaving
> when the filesystem is almost full.
What does "almost full" mean in absolute (MB) or relative (% of file system size) numbers? I.e. how much disk space should we try to reserve?

> It seems we have still a lot of usability work to do :-|
Enough to keep a whole team of experts busy for a few years. :-|
I still don't consider Sugar much more than a technology preview. It's way better than anything else, but not good (I hope that makes sense in english).

Sascha
[1] http://activities.sugarlabs.org/en-US/sugar/addon/4208
[2] git://git.sugarlabs.org/sugar/silbe.git branch t/jeb-multi
[3] git://flatty.sascha.silbe.org/backup-activity (IPv6 only)

--
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100630/d5fd197a/attachment.pgp