The patch write-devices.diff (rw-devices.diff) fix

[Darryl Dixon - Winterhouse Consulting]

Hi Zito,

> Hello,
> I faced the problem of synchronization block devices and found the patch
> write-devices.diff by Darryl Dixon, that went trough this mailing list
> http://lists.samba.org/archive/rsync/2009-October/024037.html
>
> Unfortunately the patch was one flaw for me. It doesn't improve
> performance of synchronization. When I tried to test it using something
> like:

Yes. I figured it would be something to do with the block device size
calculation, as my initial patch simply punted on that (0 as you saw) - I
didn't have time/motivation to dig through and research the necessary
magic to get good data out. Well done for finding and implementing the
required code :)

>
> ./rsync --rsync-path\="$PWD/rsync" -v --bwlimit=100 --progress
> --copy-devices --write-devices /dev/mapper/vg-pokus1
> root at localhost:/dev/mapper/vg-pokus2
>
> where pokus1 & pokus2 are two identically initialized block devices
> (logical volumes) 32MiB in size. All the data was passed trough
> local connection without the benefit. (I set --bwlimit low, so I can see
> evidently the rsync performance).
>
> By adding more -v I found, that some stat() call in the generator.c
> reports destination device size is zero. I added some code handling
> block device size. Option --ignore-times is implied for --rw-devices.
> A new patch rw-devices.diff is attached. It is combination of
> copy-devices.diff, write-devices.diff and some new code from me.

Excellent stuff. This is what I love about open source software - one
person can get the ball rolling and then the effort and expertise of
others combines to improve matters for everyone.

> Now I have questions:
>     1. Is it worth to have two separate patches copy-devices.diff,
>        write-devices.diff? (It is hard to apply them one after other,
>        because they overlays.)
>     2. Should be there two options `--copy-devices', `--write-devices'?
>        I thing one option e.g. `--rw-devices' should be sufficient.
>     3. I think the above option should collide with many other options
>        like `--archive', `--recursive',...

I agree maintaining the separate patches are hard. Personally, I'd prefer
to see just one merged patch as you suggest.

regards,
Darryl Dixon
Winterhouse Consulting Ltd
http://www.winterhouseconsulting.com