"A month of sundays ago [EMAIL PROTECTED] wrote:"
> You've got two choices. Hack the code to do the updates in-place,
> or copy the disk images to a filesystem, and treat them as files.
Mmm ... partitions too large, I fear. Hacking the code seems the better
option. But I need to know if only parts of files are sent across by the
algorithm, or not. If it is so, that would make a minor hack very practical.
> Rsync creates a duplicate of the local copy, then unlinks the original
> and renames the new copy to the original.
Yes, that doesn't worry me too much as I'm sure I can hack that into
overwriting (with offset) instead. I do need to know if the algorithm
works blockwise, though.
> Actually, I've got one for you, though. Since there are no insertions,
> you can use dd on both ends, through rsh (or ssh). use it with skip,
> seek, conv=notrunc, count=1, and some appropriate block size (the block
> size of the filesystems, maybe?), and
I.e. go through block by block, checksumming, and then fixing the
different blocks. Not a bad idea. And not too hard either. A 4GB
FS could be done in 1M checksums of 4KB. Hmm that's quite a few
MB in ascii representation. Better to use 64KB blocks at least.
But this is surely what rsync does!
> the sum command. get the sum on the master with a count=1, skip=whatever, then the
>replica. If they're different, send the master to the replica with seek and
>conv=notrunc. Make sure you do the dd AND the sum all on the remote, so all you pull
>back
> are the checksums. You can do this in a shell script, which would be
> easier than hacking rsync (use an advanced shell (bash,ksh), or perl,
> as since you need to do this, i reckon the numbers could get big.
Yes, I could hack it up in short order in a shell script (and spend
years removing bash parsing bugs :-). I'll do it to see how it looks.
Thanks
Peter
