[OpenIndiana-discuss] roughly normal rsyncing data point to point on localhost

[Peter Tribble]

On Mon, Jul 17, 2017 at 8:30 PM, Harry Putnam <reader at newsguy.com> wrote:

> Setup: OS: Openindian/hipster (A branch of Solaris 11)
>  Hardware: HP xw8600 workstation:
>            2x Intel(R) Xeon(R) CPU X5470 @ 3.33GHz - 32 GB Ram
> -------       -------       ---=---       -------      -------
>
> I curious to find out if what I'm seeing while rsyncing data from
> point to point on localhost is about what I should expect.
>
> I do realize the many factors might impact this kind of testing.
>
> But just want a non-scientific in general response from a few of you
> old hands that will if this is way off or what.
>
> Sorry if this is way tmi . . .
>
> The hardware in use is listed at the top of this message.
>
> $rsync is rsync-3.1.2
>
> I'm transferring a recently deleted linux running in Vbox vm back into
> place.
>
> $DST =  /vb/vm/<list of machines> where /vb/vm is
>                                    pool/vb and pool/vb/vm
>
> SRC = /vb/vm/.zfs/snapshot/2weeksago/vm1
>
> rsync -vvrptgd0l --stats  $SRC $DST/
>
> So, rsyncing  vm1 back into position from a snapshot
>
> -------       -------       ---=---       -------       -------
>
> I'm seeing, over time (30min), very close to 1GB transferred every 60
> seconds
>
> Can anyone say if this par for the course or what?
>

Assuming that's on a traditional spinning-rust hard drive, seems
within expectations.

That equates to about 16meg a second. The writes will tend to be
written sequentially, but the reads may be random (especially for a VM
image that has put its own data layout atop the zfs one). Even with a 128k
block size, that would be 128 IOPs which is about what you would expect
for a hard drive.

My first port of call here is to run 'iostat -xnz 1' - it will show how
much data
is being transferred (the kr/s and kw/s columns) as well as the number of
requests (r/s and w/s), as long as how busy (%b) the device is. Current
versions
also show the statistics for the pool and the underlying disk(s) so you can
see how the reads and writes get broken up between the layers.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/