Discussion on suggestions-for-re-syncing

[Freedman]

currently on my servers, I use Unison to syncronize them.
It's nice because it does bi-directional synchronization.

I'm looking into csync2 which I believe might be faster and have
better automated conflict resolution but havn't tested it.

What I'd like is a way to reactivate a mirror, either with a commant,
(instead of remounting the filesystem, which is quite disruptive), and
either manually sync then reactivate, or have chironfs auto-reactivate
after a 'sucess' from the sync function.

[Martin Fick]

I have implemented some patches to chironfs that allow an external
script to heal a disabled image if you are interested in them. The
method I used is fairly simple:

I added two new control features to the chironfs sources: the ability
to block and unblock all writes. While writes are blocked, reads
continue to be processed, but writes will hang until they are
unblocked. The healing script takes advantage of this blocking to
simply rsync the two directories while writes are blocked and then
reenables the disabled (now synced) copy and then unblocks writes.

The healing script has several options to it, including the ability to
perform a number of rsyncs before blocking writes. The idea being
that if an image has been offline for a while it could be brought
mostly up to date without interfering with operations at all. Once
the presync(s) are done, it should block writes only long enough to
update was has changed during the last presync.

The method I use to control blocking and unblocking is a little crude,
but I did not want to waste to much time on it since it may need to
evolve anyway. Simply echoing a "B" to block and a "U" to unblock to
any of the status files will do. In theory echoing a "B" will block
until all current writes have terminated so that when the echo returns
a script can be sure that the filesystems are already frozen from
chironfs. There is currently no change in the status reporting when
the block is in effect.

While writing the script, I tired to make the script as smart as
possible about configuration data so that little needs to be
provided. In this simplest of cases, only the location of the control
filesystem need be specified. But this is not reliable and so I have
a few suggestions for changes. I would add another file under each
copies directory called "root" or "mount" which would point to the
exact location in the filesystem where the copy is mounted. This
would help avoid any possible duplicated path name mistakes: i.e.
mistaking /a/b/c with /a/b_c or
/a_b/c or /a_b_c.

Also, I would add another file to these dirs called "read" or "local"
to indicate whether the copy was invoked with the colon (:) or not.
This way a smarter healing script can avoid using a (:) invoked copy
to heal from if possible!

Anyway, just some ideas. I know that others had suggested more fancy
healing stuff, but I just figured I would try to get the ball
rolling. Let me know if you are interested in any of these ideas (and/
or the code patches)?

Thanks,

-Martin