tlug: Re: root mirror (was: LILO Vs. 1024??)

[Rex Walters <rex@example.com>]

On Wed, Oct 07, 1998 at 04:19:35PM +0900, Stephen J. Turnbull wrote:
> 
>     Rex> The only thing that's missing to be able to accomplish the
>     Rex> same thing with a Linux system is the ability to "clone" an
>     Rex> ext2 filesystem reliably.  On an Auspex, ax_clonefs will
>     Rex> ensure that any modifications that occur while the copy is
>     Rex> running are handled correctly (there is actually a brief
>     Rex> lockout at the very end to ensure that all metadata is
>     Rex> synched on both sides correctly).
> 
> That sounds like a very hard problem without designing the fs around
> that requirement from the ground up.

The difficulty depends at what level of abstraction you attack the
problem.  

If block-level snapshots are available it's trivial.  With
"inode-hierarchy" snapshots (for lack of a better term) something
similar could be accomplished with a simple directory walk (tar/cpio).
There are interesting goings on in these areas on the linux-kernel list
(reiserfs, LFS, md, devfs, etc).

Without either, it's very, very tricky to do right.  One approach would
be to create a device driver to sit between the backup/dd process and
the raw disk device.  The device driver would operate similar to
PDC/Intelliguard's "BudTurbo" product if you're familiar with it.

A backup operation would go something like this:

    1) Tell the driver you want to maintain a consistent image of
       /dev/hda1 (say).  You also give it the name of a scratch
       partition that it can use as a cache area.

    2) The driver somehow puts itself before the kernel and /dev/hda1 so
       it can monitor all blocks written to that device.  (Hard bit #1)

    3) If a request arrives to write block n to /dev/hda1, the current
       block n contents are first copied away to the cache partition
       before the write is completed.  (Hard bit #2)

    4) Any process reading or writing /dev/hda1 sees everything the way
       it always was (except that writes are a bit slower).

    5) Any process reading a block from the "consistent image" device (a
       read-only device) will get either a block from the cache (if it's
       there) or the actual block from the hda1 device if no updates
       have occurred since the backup began.

    6) After the backup completes, the driver must be notified so that
       it knows to stop trying to cache all writes.  (If the cache fills
       up you can't maintain a consistent image).

In practice BudTurbo does a pretty good job of this for a variety of
Unix platforms.  I'd love to see something similar for Linux.  If I had
the expertise, time, and motivation I'd try to make something like it
myself (I think it could mostly be done in user space, but you'd need a
kernel module to help with 3 & 4 above).

Just a thought.
-- 
Rex
---------------------------------------------------------------
Next Meeting: 10 October, 12:30 Tokyo Station Yaesu central gate
Featuring the IMASY Eng. Team on "IPv6 - The Next Generation IP"
Next Nomikai: 20 November, 19:30  Tengu TokyoEkiMae 03-3275-3691
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp