"Stateless Linux" project

Bryan K. Wright bryan at ayesha.phys.Virginia.EDU
Wed Sep 15 14:43:57 UTC 2004


hp at redhat.com said:
> Dan Reed has some code written that's a bit simpler approach - it just
> rsyncs the homedir periodically.

This would work fine, at least for people with small /home directories,
and it has the distinct advantage that it can be done right now, without
a lot of development.  It might be a problem for folks with larger /home
directories, though.  On my laptop, I have about 20GB of user files
(images, maps, data, documents) and it takes a few minutes of disk
grinding for rsync just to walk the tree and decide what's changed.
This might be prohibitive (or at least prohibitively annoying) for the
user.  It also cuts into the battery life.

Another possible user-space option would be something based on SGI::FAM.
Around here, I use a fam-based intrusion-detection system to monitor
a few system files that are commonly modified  by root kits, and send
me a notice when one changes.  A similar system could monitor the
directories in /home and, whenever a file changes, queue it up
for synchronization with a remote mirror.  This has the advantage of
not needing to walk the whole file tree repeatedly, as you'd need
to do with rsync.  I suspect that you might run into problems with
the number of file descriptors or memory use for large /home 
directories, though.  When I get a chance, I'll whip up a script
and try it out on my laptop.

Moving out of user space, and requiring some of development, you
could have the kernel's VFS layer generate a notice, maybe via DBUS, 
whenever a file changes.  It'd be nice to be able to turn this on only
for selected filesystems: monitor /home, but don't bother with
/var, for example.  A client would watch for changes and queue up
files for synchronization.

Back to my original suggestion of a "RAID 1" mirror composed of
a local disk and a network block device:  It seems like you'd need
to make the RAID system smart enough to realize that one device
has much bigger latencies than the other, otherwise you'd get
performance problems.  You'd want to preferentially read from
the local disk, for example, and you'd want to queue up writes
to the remote disk instead of waiting for them to complete
synchronously.  I don't know if the current software RAID 
implementation supports this sort of thing.

Ideas are easy. Coding's hard.  Thanks again for pulling together
a lot of disconnected useful ideas into "stateless linux" and 
starting to instantiate them in code.  

						Bryan
-- 
===============================================================================
Bryan Wright                |"If you take cranberries and stew them like 
Physics Department          | applesauce, they taste much more like prunes 
University of Virginia      | than rhubarb does."  --  Groucho 
Charlottesville, VA  22901  |			
(434) 924-7218              |         bryan at virginia.edu
===============================================================================






More information about the fedora-devel-list mailing list