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

Re: Redhat stateless Linux and git

From
GBGeert Bosch <bosch@adacore.com>
Date
Jun 11, 2006, 12:21 UTC
Message-ID
<D5AC73C4-5A2F-482E-9B45-71A72C62D670@adacore.com>
In-Reply-To
<9e4733910606091559m6a88e864m16f9d75a507ee684@mail.gmail.com>
On Jun 9, 2006, at 18:59, Jon Smirl wrote:
Show 5 quoted lines
> Redhat is looking for a scheme to sync the disk system of their
> stateless Linux client. They were using rsync and now they are looking
> at doing it with LVM.
>
> What about using git?

The data model is fine in principle, but git as-is isn't suitable for general backup/sync-like schemes. Large (multi-GB) files are not really supported yet. Still, I think the underlying data model, with some modifications to split large files on content-determined boundaries, would be really great for distributed filesystems.

Many people using laptops these days connect to different filesystems on their office networks, home networks, digital cameras and even their PDA, cellphone and MP3-player. What is commonly described as "synching", really is just a merge between different branches. All arguments in favor of using a distributed SCM hold here too.

Right now I'm using a hodge-podge of different manual and semi-automated methods to keep my local filesystem with 1.5M files totalling 90GB somewhat in synch with various homedirectories on different remote systems and backup disks. IMO, git is tantalizing close to be able to handle this, just needs to get a bit more scalable. Probably you'd want to use a different user interface as well, but all the underlying data structures and merge strategies may be equally valid.

   -Geert
Previous: Jon SmirlNext: Jon Smirl
Message 2 of 3 in “Redhat stateless Linux and git”
  1. Jon SmirlJun 9, 2006
  2. Geert BoschJun 11, 2006
  3. Jon SmirlJun 11, 2006

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.