From: Jon Smirl Date: Sun, 11 Jun 2006 15:07:57 GMT Subject: Re: Redhat stateless Linux and git Message-ID: <9e4733910606110807m41fe82er9c4876a88336209c@mail.gmail.com> In-Reply-To: On 6/11/06, Geert Bosch wrote: > > On Jun 9, 2006, at 18:59, Jon Smirl wrote: > > 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. That's why I though stateless Linux was a good place to start. The client is read only so it is the simplest case to start with. I would much prefer a file orientated system for syncing over a block oriented one, with the block one there is no easy way to tell what is being copied to your machine. I added the stateless list to the cc, maybe they'll join in. -- Jon Smirl jonsmirl@gmail.com