<I meant to send this to the list>
"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
