:I briefly thought the low I/O figures on da1 (mirroring from da0 to da1) might
:have been a new quirk:
:
:> iostat -w1
: tty ad0 da0 da1 cpu
: tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
: 2 465 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 4 0 10 1 85
: 0 80 0.00 0 0.00 64.00 643 40.21 64.00 4 0.25 21 0 42 2 35
: 0 80 0.00 0 0.00 63.82 683 42.59 60.00 4 0.23 28 0 37 3 32
: 0 80 0.00 0 0.00 63.79 614 38.26 64.00 6 0.37 20 0 38 1 41
:
:...but it completed in appropriate time and all the data appears to be there, so
:I'm not sure if HAMMER was being smart enough to skip over what existed from a
:previous interrupted copy or what. I don't really remember whether the
:pre-patch stats actually looked any different for the destination disk.
:
:[SATA disks on a mpt0, write caches enabled.]
The more likely case is that the mirror stream repeated the data but
since the target already had it there was no need to re-write it on
the target. In that case the only disk activity on the target will
be accessing and comparing the meta-data.
It tries to stage the mirroring stream so it can pick up where it
left off but it's a bit of a hack. If it managed to complete a
batch then it certainly will pick up after the completion and not
resend the whole batch. I need to redo the code to actually
calculate the batch size and split things up based on that instead
of splitting things up based on B-Tree key ranges.
This applies to initial mirroring only, of course. Once the initial
copy is finished all later mirroring runs will be incremental.
-Matt
Matthew Dillon
<dillon@backplane.com>