[Sugar-devel] Journal Backup/Restore UI

[Tomeu Vizoso]

On Mon, Mar 29, 2010 at 14:26, Bernie Innocenti <bernie at codewiz.org> wrote:
> On Mon, 2010-03-29 at 10:14 +0200, Martin Langhoff wrote:
>> On Mon, Mar 29, 2010 at 2:22 AM, Bernie Innocenti <bernie at codewiz.org> wrote:
>> > However, it looks like it would take a couple of months of effort to get
>>
>> I think you are overengineering this.
>>
>>  - Single-file restore is well solved by Moodle's backup/restore UI + Browse
>>
>>  - As you found out, librsync isn't what you want... just rsync _all_
>> of it, and then inject each entry using copy-to-journal. It doesn't
>> fix the disk usage problem, but it sure solves the "restart datastore"
>> and the associated issue that you are deleting whatever new was in the
>> Journal. You are not "restoring".
>
> Ok, how about:
>
>  - an initial rsync with no destination to list what's available
>
>  - rsync one file at a time + copy-to-journal.
>
> There's still the possibility that one very large file would make the
> entire process fail.
>
> Does the datastore support creating entries with no data and writing the
> data at a later time? I don't know much about the datastore design, but
> I got that we use uuids as keys, not hashes of the content.

Yup.

We do use hashes but only internally for detecting duplicates.

http://wiki.sugarlabs.org/go/Development_Team/Datastore_Rewrite

Regards,

Tomeu

>
>> Stoopid question: can't you 'FUSE'-mount the XS directory with sshfs
>> and then use copy-to-journal? Latency will make that a tad slower, but
>> the local-diskspace issue is gone.
>
> Very good idea.
>
>
> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>