git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: crash proof / recovery from power loss

From
Martin Langhoff <martin.langhoff@gmail.com>
Date
Jun 25, 2009, 13:31 UTC
Message-ID
<46a038f90906250631k5e702f66g50a6e60db8bab856@mail.gmail.com>
In-Reply-To
<20090623210556.GB31015@twin.sascha.silbe.org>

On Tue, Jun 23, 2009 at 11:05 PM, Sascha Silbe <sascha-ml-devel-vcs-git@silbe.org> wrote:

> I'm going to use git as a back end for the Sugar data store / Journal. [1]
> One thing I'm worried about is how it's going to behave if a crash (e.g. power loss - no corruption) occurs.
> What can happen in such a case? Is it always recoverable and if so, how?

Git is outrageously good in keeping things sane. On that front, you won't see any problems.

Now... there is one area where it will hurt lots: storing large binary blobs. Git assumes that every file is very small in comparison with available physical memory.

 - Sugar utilities already can create files larger than available
memory. Think Record.xo, etoys, etc.
 - Many sugar target platforms are _very_ memory constrained. XO-1
being the prime example.

Lots of what git does would be good in the Journal. But some of the core assumptions are not well matched.

There are some tunables in git that might help. And maybe you can sidestep the harder corners of the problem by having a threshold, and handling large files separately.

hth,
m
--
martin.langhoff@gmail.com
martin@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
Previous: Jakub Narebski
Message 3 of 3 in “crash proof / recovery from power loss”
  1. Sascha SilbeJun 23, 2009
  2. Jakub NarebskiJun 25, 2009
  3. Martin LanghoffJun 25, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.