On Wed, 30 Apr 2008, Gareth Bult wrote:
It would certainly ber beneficial in the cases when the network speed
is slow (e.g. WAN replication).
So long as it's server side AFR and not client-side ... ?
Sure.
I'm guessing there would need to be some server side logic to ensure
that local servers generated their own hashes and only exchanged the
hashes over the network rather than the data ?
Indeed - same as rsync does.
Journal per se wouldn't work, because that implies fixed size and write-ahead logging.
What would be required here is more like the snapshot style undo logging.
A journal wouldn't work ?!
You mean it's effectiveness would be governed by it's size?
Among other things. A "journal" just isn't suitable for this sort of
thing.
1) Categorically establish whether each server is connected and up to date
for the file being checked, and only log if the server has disconnected.
This involves overhead.
Surely you would log anyway, as there could easily be latency between an
actual "down" and one's ability to detect it .. in which case detecting
whether a server has disconnected it a moot point.
Not really. A connected client/server will have a live/working TCP
connection open. Read-locks don't matter as they can be served locally,
but when a write occurs, the file gets locked. If a remote machine doesn't
ack the lock, and/or it's TCP connection resets, then it's safe to assume
that it's not connected.
In terms of the
overhead of logging, I guess this would be a decision for the sysadmin
concerned, whether the overhead of logging to a journal was worthwhile
.vs. the potential issues involved in recovering from an outage?
That complicates things further, then. You'd essentially have asynchronous
logging/replication. At that point you pretty much have to log all writes
all the time. That means potentially huge space and speed overheads.
From my point of view, if journaling halved my write performance (which
it wouldn't) I wouldn't even have to think about it.
Actually, saving an undo-log a-la snapshots, which is what would be
required, _WOULD_ halve your write performance on all surviving servers if
one server was out. If multiple servers were out, you could probably work
around some of this with merging/splitting the undo logs for various
machines, so your write performance would generally be around 1/2 of
standard, but wouldn't end up degrading to 1/n+1 where n is the number of
failed servers for which the logging needs to be done.
The problem that arises then is that the fast(er) resyncs on small changes
come at the cost of massive slowdown in operation when you have multiple
downed servers. As the number of servers grows, this rapidly stops being a
workable solution.
Ok, I don't know about anyone else, but my setups all rely on
consistency rather than peaks and troughs. I'd far rather run a journal
at half potential speed, and have everything run at that speed all the
time .. than occasionally have to stop the entire setup while the system
recovers, or essentially wait for 5-10 minutes while the system re-syncs
after a node is reloaded.
There may be a way to address the issue of halting the rest of the cluster
during the sync, though. Read lock on a syncing file shouldn't stop other
read locks. Of course, it will block writes while the file syncs and the
reading app finishes the operation.
Gordan
