[OmniOS-discuss] announcement znapzend
Theo Schlossnagle
jesus at omniti.com
Mon Aug 11 23:27:55 UTC 2014
OmniOS ships with pipeviewer (pv), if you use pv -s <several megs>, it
would have close to the same effect as using mbuffer.
On Mon, Aug 11, 2014 at 2:06 AM, Hafiz Rafibeyli <rafibeyli at gmail.com>
wrote:
> Tobias thank you for great job,it was missing backup part for zfs on
> omnios,
>
> I think ssh will slow for bigger datasets,as you mention znapzend 0.11
> supporting use of mbuffer.
>
> I could not find mbuffer package for omnios,could you explain how to
> setup/use mbuffer on omnios please?
>
> regards
>
>
>
> ----- Original Message -----
> From: omnios-discuss-request at lists.omniti.com
> To: omnios-discuss at lists.omniti.com
> Sent: Tuesday, 29 July, 2014 10:29:42 PM
> Subject: OmniOS-discuss Digest, Vol 28, Issue 8
>
> Send OmniOS-discuss mailing list submissions to
> omnios-discuss at lists.omniti.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
> or, via email, send a message with subject or body 'help' to
> omnios-discuss-request at lists.omniti.com
>
> You can reach the person managing the list at
> omnios-discuss-owner at lists.omniti.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OmniOS-discuss digest..."
>
>
> Today's Topics:
>
> 1. announcement znapzend a new zfs backup tool (Tobias Oetiker)
> 2. Re: announcement znapzend a new zfs backup tool
> (Theo Schlossnagle)
> 3. Re: announcement znapzend a new zfs backup tool (Saso Kiselkov)
> 4. Re: Slow scrub performance (wuffers)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 29 Jul 2014 17:50:02 +0200 (CEST)
> From: Tobias Oetiker <tobi at oetiker.ch>
> To: omnios-discuss at lists.omniti.com
> Subject: [OmniOS-discuss] announcement znapzend a new zfs backup tool
> Message-ID: <alpine.DEB.2.02.1407291748500.6752 at froburg.oetiker.ch>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Just out:
>
> ZnapZend a Multilevel Backuptool for ZFS
>
> It is on Github. Check out
>
> http://www.znapzend.org
>
> cheers
> tobi
>
> --
> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 29 Jul 2014 11:54:07 -0400
> From: Theo Schlossnagle <jesus at omniti.com>
> To: "OmniOS-discuss at lists.omniti.com"
> <omnios-discuss at lists.omniti.com>
> Subject: Re: [OmniOS-discuss] announcement znapzend a new zfs backup
> tool
> Message-ID:
> <
> CACLsAptC_wDb+Stkw2-jZkgp7oQZ4OwEUWG_Nnrm_xkaoOkGRg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Awesome!
>
>
> On Tue, Jul 29, 2014 at 11:50 AM, Tobias Oetiker <tobi at oetiker.ch> wrote:
>
> > Just out:
> >
> > ZnapZend a Multilevel Backuptool for ZFS
> >
> > It is on Github. Check out
> >
> > http://www.znapzend.org
> >
> > cheers
> > tobi
> >
> > --
> > Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> > www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
> >
> > _______________________________________________
> > OmniOS-discuss mailing list
> > OmniOS-discuss at lists.omniti.com
> > http://lists.omniti.com/mailman/listinfo/omnios-discuss
> >
>
>
>
> --
>
> Theo Schlossnagle
>
> http://omniti.com/is/theo-schlossnagle
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://omniosce.org/ml-archive/attachments/20140729/f8adbbf5/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Tue, 29 Jul 2014 17:59:18 +0200
> From: Saso Kiselkov <skiselkov.ml at gmail.com>
> To: omnios-discuss at lists.omniti.com
> Subject: Re: [OmniOS-discuss] announcement znapzend a new zfs backup
> tool
> Message-ID: <53D7C4D6.5060308 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 7/29/14, 5:50 PM, Tobias Oetiker wrote:
> > Just out:
> >
> > ZnapZend a Multilevel Backuptool for ZFS
> >
> > It is on Github. Check out
> >
> > http://www.znapzend.org
>
> Neat, especially the feature that the backup config is part of a
> dataset's properties. Very cool.
>
> --
> Saso
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 29 Jul 2014 15:29:38 -0400
> From: wuffers <moo at wuffers.net>
> To: Richard Elling <richard.elling at richardelling.com>
> Cc: omnios-discuss <omnios-discuss at lists.omniti.com>
> Subject: Re: [OmniOS-discuss] Slow scrub performance
> Message-ID:
> <
> CA+tR_KwX_1HN4tVa+-ZOFJk2mN7RE-nFh31sMcTNo7TJJjfyLg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Going to try to answer both responses in one message..
>
> Short answer, yes. ? Keep in mind that
> >
> > 1. a scrub runs in the background (so as not to impact production I/O,
> > this was not always the case and caused serious issues in the past with a
> > pool being unresponsive due to a scrub)
> >
> > 2. a scrub essentially walks the zpool examining every transaction in
> > order (as does a resilver)
> >
> > So the time to complete a scrub depends on how many write transactions
> > since the pool was created (which is generally related to the amount of
> > data but not always). You are limited by the random I/O capability of the
> > disks involved. With VMs I assume this is a file server, so the I/O size
> > will also affect performance.
>
>
> I haven't noticed any slowdowns in our virtual environments, so I guess
> that's a good thing it's so low priority that it doesn't impact workloads.
>
> Run the numbers? you are scanning 24.2TB at about 5.5MB/sec ? 4,613,734
> > seconds or 54 days. And that assumes the same rate for all of the scan.
> The
> > rate will change as other I/O competes for resources.
> >
>
> The number was fluctuating when I started the scrub, and I had seen it go
> as high as 35MB/s at one point. I am certain that our Hyper-V workload has
> increased since the last scrub, so this does make sense.
>
>
> > Looks like you have a fair bit of activity going on (almost 1MB/sec of
> > writes per spindle).
> >
>
> As Richard correctly states below, this is the aggregate since boot (uptime
> ~56 days). I have another output from iostat as per his instructions below.
>
>
> > Since this is storage for VMs, I assume this is the storage server for
> > separate compute servers? Have you tuned the block size for the file
> share
> > you are using? That can make a huge difference in performance.
> >
>
> Both the Hyper-V and VMware LUNs are created with 64K block sizes. From
> what I've read of other performance and tuning articles, that is the
> optimal block size (I did some limited testing when first configuring the
> SAN, but results were somewhat inconclusive). Hyper-V hosts our testing
> environment (we integrate with TFS, a MS product, so we have no choice
> here) and probably make up the bulk of the workload (~300+ test VMs with
> various OSes). VMware hosts our production servers (Exchange, file servers,
> SQL, AD, etc - ~50+ VMs).
>
> I also noted that you only have a single LOG device. Best Practice is to
> > mirror log devices so you do not lose any data in flight if hit by a
> power
> > outage (of course, if this server has more UPS runtime that all the
> clients
> > that may not matter).
> >
>
> Actually, I do have a mirror ZIL device, it's just disabled at this time
> (my ZIL devices are ZeusRAMs). At some point, I was troubleshooting some
> kernel panics (turned out to be a faulty SSD on the rpool), and hadn't
> re-enabled it yet. Thanks for the reminder (and yes, we do have a UPS as
> well).
>
> And oops.. re-attaching the ZIL as a mirror triggered a resilver now,
> suspending or canceling the scrub? Will monitor this and restart the scrub
> if it doesn't by itself.
>
> pool: tank
> state: ONLINE
> status: One or more devices is currently being resilvered. The pool will
> continue to function, possibly in a degraded state.
> action: Wait for the resilver to complete.
> scan: resilver in progress since Tue Jul 29 14:48:48 2014
> 3.89T scanned out of 24.5T at 3.06G/s, 1h55m to go
> 0 resilvered, 15.84% done
>
> At least it's going very fast. EDIT: Now about 67% done as I finish writing
> this, speed dropping to ~1.3G/s.
>
> maybe, maybe not
> >>
> >> this is slower than most, surely slower than desired
> >>
> >
> Unfortunately reattaching the mirror to my log device triggered a resilver.
> Not sure if this is desired behavior, but yes, 5.5MB/s seems quite slow.
> Hopefully after the resilver the scrub will progress where it left off.
>
>
> > The estimate is often very wrong, especially for busy systems.
> >> If this is an older ZFS implementation, this pool is likely getting
> >> pounded by the
> >> ZFS write throttle. There are some tunings that can be applied, but the
> >> old write
> >> throttle is not a stable control system, so it will always be a little
> >> bit unpredictable.
> >>
> >
> The system is on r151008 (my BE states that I upgraded back in February,
> putting me in r151008j or so), with all the pools upgraded for the new
> enhancements as well as activating the new L2ARC compression feature.
> Reading the release notes, the ZFS write throttle enhancements were in
> since r151008e so I should be good there.
>
>
> > # iostat -xnze
> >>
> >>
> >> Unfortunately, this is the performance since boot and is not suitable
> for
> >> performance
> >> analysis unless the system has been rebooted in the past 10 minutes or
> >> so. You'll need
> >> to post the second batch from "iostat -zxCn 60 2"
> >>
> >
> Ah yes, that was my mistake. Output from second count (before re-attaching
> log mirror):
>
> # iostat -zxCn 60 2
>
> extended device statistics
> r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
> 255.7 1077.7 6294.0 41335.1 0.0 1.9 0.0 1.4 0 153 c1
> 5.3 23.9 118.5 811.9 0.0 0.0 0.0 1.1 0 3
> c1t5000C50055F8723Bd0
> 5.9 14.5 110.0 834.3 0.0 0.0 0.0 1.3 0 2
> c1t5000C50055E66B63d0
> 5.6 16.6 123.8 822.7 0.0 0.0 0.0 1.3 0 2
> c1t5000C50055F87E73d0
> 4.7 27.8 118.6 796.6 0.0 0.0 0.0 1.3 0 3
> c1t5000C50055F8BFA3d0
> 5.6 14.5 139.7 833.8 0.0 0.0 0.0 1.6 0 3
> c1t5000C50055F9E123d0
> 4.4 27.1 112.3 825.2 0.0 0.0 0.0 0.8 0 2
> c1t5000C50055F9F0B3d0
> 5.0 20.2 121.7 803.4 0.0 0.0 0.0 1.2 0 3
> c1t5000C50055F9D3B3d0
> 5.4 26.4 137.0 857.3 0.0 0.0 0.0 1.4 0 4
> c1t5000C50055E4FDE7d0
> 4.7 12.3 123.7 832.7 0.0 0.0 0.0 2.0 0 3
> c1t5000C50055F9A607d0
> 5.0 23.9 125.9 830.9 0.0 0.0 0.0 1.3 0 3
> c1t5000C50055F8CDA7d0
> 4.5 31.4 112.2 814.6 0.0 0.0 0.0 1.1 0 3
> c1t5000C50055E65877d0
> 5.2 24.4 130.6 872.5 0.0 0.0 0.0 1.2 0 3
> c1t5000C50055F9E7D7d0
> 4.1 21.8 103.7 797.2 0.0 0.0 0.0 1.1 0 3
> c1t5000C50055FA0AF7d0
> 5.5 24.8 129.8 802.8 0.0 0.0 0.0 1.5 0 4
> c1t5000C50055F9FE87d0
> 5.7 17.7 137.2 797.6 0.0 0.0 0.0 1.4 0 3
> c1t5000C50055F9F91Bd0
> 6.0 30.6 139.1 852.0 0.0 0.1 0.0 1.5 0 4
> c1t5000C50055F9FEABd0
> 6.1 34.1 137.8 929.2 0.0 0.1 0.0 1.9 0 6
> c1t5000C50055F9F63Bd0
> 4.1 15.9 101.8 791.4 0.0 0.0 0.0 1.6 0 3
> c1t5000C50055F9F3EBd0
> 6.4 23.2 155.2 878.6 0.0 0.0 0.0 1.1 0 3
> c1t5000C50055F9F80Bd0
> 4.5 23.5 106.2 825.4 0.0 0.0 0.0 1.1 0 3
> c1t5000C50055F9FB8Bd0
> 4.0 23.2 101.1 788.9 0.0 0.0 0.0 1.3 0 3
> c1t5000C50055F9F92Bd0
> 4.4 11.3 125.7 782.3 0.0 0.0 0.0 1.9 0 3
> c1t5000C50055F8905Fd0
> 4.6 20.4 129.2 823.0 0.0 0.0 0.0 1.5 0 3
> c1t5000C50055F8D48Fd0
> 5.1 19.7 142.9 887.2 0.0 0.0 0.0 1.7 0 3
> c1t5000C50055F9F89Fd0
> 5.6 11.4 129.1 776.0 0.0 0.0 0.0 1.9 0 3
> c1t5000C50055F9EF2Fd0
> 5.6 23.7 137.4 811.9 0.0 0.0 0.0 1.2 0 3
> c1t5000C50055F8C3ABd0
> 6.8 13.9 132.4 834.3 0.0 0.0 0.0 1.8 0 3
> c1t5000C50055E66053d0
> 5.2 26.7 126.9 857.3 0.0 0.0 0.0 1.2 0 3
> c1t5000C50055E66503d0
> 4.2 27.1 104.6 825.2 0.0 0.0 0.0 1.0 0 3
> c1t5000C50055F9D3E3d0
> 5.2 30.7 140.9 852.0 0.0 0.1 0.0 1.5 0 4
> c1t5000C50055F84FB7d0
> 5.4 16.1 124.3 791.4 0.0 0.0 0.0 1.7 0 3
> c1t5000C50055F8E017d0
> 3.8 31.4 89.7 814.6 0.0 0.0 0.0 1.1 0 4
> c1t5000C50055E579F7d0
> 4.6 27.5 116.0 796.6 0.0 0.1 0.0 1.6 0 4
> c1t5000C50055E65807d0
> 4.0 21.5 99.7 797.2 0.0 0.0 0.0 1.1 0 3
> c1t5000C50055F84A97d0
> 4.7 20.2 116.3 803.4 0.0 0.0 0.0 1.4 0 3
> c1t5000C50055F87D97d0
> 5.0 11.5 121.5 776.0 0.0 0.0 0.0 2.0 0 3
> c1t5000C50055F9F637d0
> 4.9 11.3 112.4 782.3 0.0 0.0 0.0 2.3 0 3
> c1t5000C50055E65ABBd0
> 5.3 11.8 142.5 832.7 0.0 0.0 0.0 2.4 0 3
> c1t5000C50055F8BF9Bd0
> 5.0 20.3 121.4 823.0 0.0 0.0 0.0 1.7 0 3
> c1t5000C50055F8A22Bd0
> 6.6 24.3 170.3 872.5 0.0 0.0 0.0 1.3 0 3
> c1t5000C50055F9379Bd0
> 5.8 16.3 121.7 822.7 0.0 0.0 0.0 1.3 0 2
> c1t5000C50055E57A5Fd0
> 5.3 17.7 146.5 797.6 0.0 0.0 0.0 1.4 0 3
> c1t5000C50055F8CCAFd0
> 5.7 34.1 141.5 929.2 0.0 0.1 0.0 1.7 0 5
> c1t5000C50055F8B80Fd0
> 5.5 23.8 125.7 830.9 0.0 0.0 0.0 1.2 0 3
> c1t5000C50055F9FA1Fd0
> 5.0 23.2 127.9 878.6 0.0 0.0 0.0 1.1 0 3
> c1t5000C50055E65F0Fd0
> 5.2 14.0 163.7 833.8 0.0 0.0 0.0 2.0 0 3
> c1t5000C50055F8BE3Fd0
> 4.6 18.9 122.8 887.2 0.0 0.0 0.0 1.6 0 3
> c1t5000C50055F8B21Fd0
> 5.5 23.6 137.4 825.4 0.0 0.0 0.0 1.5 0 3
> c1t5000C50055F8A46Fd0
> 4.9 24.6 116.7 802.8 0.0 0.0 0.0 1.4 0 4
> c1t5000C50055F856CFd0
> 4.9 23.4 120.8 788.9 0.0 0.0 0.0 1.4 0 3
> c1t5000C50055E6606Fd0
> 234.9 170.1 4079.9 11127.8 0.0 0.2 0.0 0.5 0 9 c2
> 119.0 28.9 2083.8 670.8 0.0 0.0 0.0 0.3 0 3
> c2t500117310015D579d0
> 115.9 27.4 1996.1 634.2 0.0 0.0 0.0 0.3 0 3
> c2t50011731001631FDd0
> 0.0 113.8 0.0 9822.8 0.0 0.1 0.0 1.0 0 2
> c2t5000A72A3007811Dd0
> 0.1 18.5 0.0 64.8 0.0 0.0 0.0 0.0 0 0 c4
> 0.1 9.2 0.0 32.4 0.0 0.0 0.0 0.0 0 0 c4t0d0
> 0.0 9.2 0.0 32.4 0.0 0.0 0.0 0.0 0 0 c4t1d0
> 229.8 58.1 3987.4 1308.0 0.0 0.1 0.0 0.3 0 6 c12
> 114.2 27.7 1994.8 626.0 0.0 0.0 0.0 0.3 0 3
> c12t500117310015D59Ed0
> 115.5 30.4 1992.6 682.0 0.0 0.0 0.0 0.3 0 3
> c12t500117310015D54Ed0
> 0.1 17.1 0.0 64.8 0.0 0.0 0.6 0.1 0 0 rpool
> 720.3 1298.4 14361.2 53770.8 18.7 2.3 9.3 1.1 6 68 tank
>
> Is 153% busy correct on c1? Seems to me that disks are quite "busy", but
> are handling the workload just fine (wait at 6% and asvc_t at 1.1ms)
>
> Interestingly, this is the same output now that the resilver is running:
>
> extended device statistics
> r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
> 2876.9 1041.1 25400.7 38189.1 0.0 37.9 0.0 9.7 0 2011 c1
> 60.8 26.1 540.1 845.2 0.0 0.7 0.0 8.3 0 39
> c1t5000C50055F8723Bd0
> 58.4 14.2 511.6 740.7 0.0 0.7 0.0 10.1 0 39
> c1t5000C50055E66B63d0
> 60.2 16.3 529.3 756.1 0.0 0.8 0.0 10.1 0 41
> c1t5000C50055F87E73d0
> 57.5 24.9 527.6 841.7 0.0 0.7 0.0 9.0 0 40
> c1t5000C50055F8BFA3d0
> 57.9 14.5 543.5 765.1 0.0 0.7 0.0 9.8 0 38
> c1t5000C50055F9E123d0
> 57.9 23.9 516.6 806.9 0.0 0.8 0.0 9.3 0 40
> c1t5000C50055F9F0B3d0
> 59.8 24.6 554.1 857.5 0.0 0.8 0.0 9.6 0 42
> c1t5000C50055F9D3B3d0
> 56.5 21.0 480.4 715.7 0.0 0.7 0.0 8.9 0 37
> c1t5000C50055E4FDE7d0
> 54.8 9.7 473.5 737.9 0.0 0.7 0.0 11.2 0 39
> c1t5000C50055F9A607d0
> 55.8 20.2 457.3 708.7 0.0 0.7 0.0 9.9 0 40
> c1t5000C50055F8CDA7d0
> 57.8 28.6 487.0 796.1 0.0 0.9 0.0 9.9 0 45
> c1t5000C50055E65877d0
> 60.8 27.1 572.6 823.7 0.0 0.8 0.0 8.8 0 41
> c1t5000C50055F9E7D7d0
> 55.8 21.1 478.2 766.6 0.0 0.7 0.0 9.7 0 40
> c1t5000C50055FA0AF7d0
> 57.0 22.8 528.3 724.5 0.0 0.8 0.0 9.6 0 41
> c1t5000C50055F9FE87d0
> 56.2 10.8 465.2 715.6 0.0 0.7 0.0 10.4 0 38
> c1t5000C50055F9F91Bd0
> 59.2 29.4 524.6 740.9 0.0 0.8 0.0 8.9 0 41
> c1t5000C50055F9FEABd0
> 57.3 30.7 496.7 788.3 0.0 0.8 0.0 9.1 0 42
> c1t5000C50055F9F63Bd0
> 55.5 16.3 461.9 652.9 0.0 0.7 0.0 10.1 0 39
> c1t5000C50055F9F3EBd0
> 57.2 22.1 495.1 701.1 0.0 0.8 0.0 9.8 0 41
> c1t5000C50055F9F80Bd0
> 59.5 30.2 543.1 741.8 0.0 0.9 0.0 9.6 0 45
> c1t5000C50055F9FB8Bd0
> 56.5 25.1 515.4 786.9 0.0 0.7 0.0 8.6 0 38
> c1t5000C50055F9F92Bd0
> 61.8 12.5 540.6 790.9 0.0 0.8 0.0 10.3 0 41
> c1t5000C50055F8905Fd0
> 57.0 19.8 521.0 774.3 0.0 0.7 0.0 9.6 0 39
> c1t5000C50055F8D48Fd0
> 56.3 16.3 517.7 724.7 0.0 0.7 0.0 9.9 0 38
> c1t5000C50055F9F89Fd0
> 57.0 13.4 504.5 790.5 0.0 0.8 0.0 10.7 0 40
> c1t5000C50055F9EF2Fd0
> 55.0 26.1 477.6 845.2 0.0 0.7 0.0 8.3 0 36
> c1t5000C50055F8C3ABd0
> 57.8 14.1 518.7 740.7 0.0 0.8 0.0 10.8 0 41
> c1t5000C50055E66053d0
> 55.9 20.8 490.2 715.7 0.0 0.7 0.0 9.0 0 37
> c1t5000C50055E66503d0
> 57.0 24.1 509.7 806.9 0.0 0.8 0.0 10.0 0 41
> c1t5000C50055F9D3E3d0
> 59.1 29.2 504.1 740.9 0.0 0.8 0.0 9.3 0 44
> c1t5000C50055F84FB7d0
> 54.4 16.3 449.5 652.9 0.0 0.7 0.0 10.4 0 39
> c1t5000C50055F8E017d0
> 57.8 28.4 503.3 796.1 0.0 0.9 0.0 10.1 0 45
> c1t5000C50055E579F7d0
> 58.2 24.9 502.0 841.7 0.0 0.8 0.0 9.2 0 40
> c1t5000C50055E65807d0
> 58.2 20.7 513.4 766.6 0.0 0.8 0.0 9.8 0 41
> c1t5000C50055F84A97d0
> 56.5 24.9 508.0 857.5 0.0 0.8 0.0 9.2 0 40
> c1t5000C50055F87D97d0
> 53.4 13.5 449.9 790.5 0.0 0.7 0.0 10.7 0 38
> c1t5000C50055F9F637d0
> 57.0 11.8 503.0 790.9 0.0 0.7 0.0 10.6 0 39
> c1t5000C50055E65ABBd0
> 55.4 9.6 461.1 737.9 0.0 0.8 0.0 11.6 0 40
> c1t5000C50055F8BF9Bd0
> 55.7 19.7 484.6 774.3 0.0 0.7 0.0 9.9 0 40
> c1t5000C50055F8A22Bd0
> 57.6 27.1 518.2 823.7 0.0 0.8 0.0 8.9 0 40
> c1t5000C50055F9379Bd0
> 59.6 17.0 528.0 756.1 0.0 0.8 0.0 10.1 0 41
> c1t5000C50055E57A5Fd0
> 61.2 10.8 530.0 715.6 0.0 0.8 0.0 10.7 0 40
> c1t5000C50055F8CCAFd0
> 58.0 30.8 493.3 788.3 0.0 0.8 0.0 9.4 0 43
> c1t5000C50055F8B80Fd0
> 56.5 19.9 490.7 708.7 0.0 0.8 0.0 10.0 0 40
> c1t5000C50055F9FA1Fd0
> 56.1 22.4 484.2 701.1 0.0 0.7 0.0 9.5 0 39
> c1t5000C50055E65F0Fd0
> 59.2 14.6 560.9 765.1 0.0 0.7 0.0 9.8 0 39
> c1t5000C50055F8BE3Fd0
> 57.9 16.2 546.0 724.7 0.0 0.7 0.0 10.1 0 40
> c1t5000C50055F8B21Fd0
> 59.5 30.0 553.2 741.8 0.0 0.9 0.0 9.8 0 45
> c1t5000C50055F8A46Fd0
> 57.4 22.5 504.0 724.5 0.0 0.8 0.0 9.6 0 41
> c1t5000C50055F856CFd0
> 58.4 24.6 531.4 786.9 0.0 0.7 0.0 8.4 0 38
> c1t5000C50055E6606Fd0
> 511.0 161.4 7572.1 11260.1 0.0 0.3 0.0 0.4 0 14 c2
> 252.3 20.1 3776.3 458.9 0.0 0.1 0.0 0.2 0 6
> c2t500117310015D579d0
> 258.8 18.0 3795.7 350.0 0.0 0.1 0.0 0.2 0 6
> c2t50011731001631FDd0
> 0.0 123.4 0.0 10451.1 0.0 0.1 0.0 1.0 0 3
> c2t5000A72A3007811Dd0
> 0.2 16.1 1.9 56.7 0.0 0.0 0.0 0.0 0 0 c4
> 0.2 8.1 1.6 28.3 0.0 0.0 0.0 0.0 0 0 c4t0d0
> 0.0 8.1 0.3 28.3 0.0 0.0 0.0 0.0 0 0 c4t1d0
> 495.6 163.6 7168.9 11290.3 0.0 0.2 0.0 0.4 0 14 c12
> 0.0 123.4 0.0 10451.1 0.0 0.1 0.0 1.0 0 3
> c12t5000A72B300780FFd0
> 248.2 18.1 3645.8 323.0 0.0 0.1 0.0 0.2 0 5
> c12t500117310015D59Ed0
> 247.4 22.1 3523.1 516.2 0.0 0.1 0.0 0.2 0 6
> c12t500117310015D54Ed0
> 0.2 14.8 1.9 56.7 0.0 0.0 0.6 0.1 0 0 rpool
> 3883.5 1357.7 40141.6 60739.5 22.8 38.6 4.4 7.4 54 100 tank
>
> It is very busy with alot of wait % and higher asvc_t (2011% busy on c1?!).
> I'm assuming resilvers are alot more aggressive than scrubs.
>
> There are many variables here, the biggest of which is the current
> >> non-scrub load.
> >>
> >
> I might have lost 2 weeks of scrub time, depending on whether the scrub
> will resume where it left off. I'll update when I can.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://omniosce.org/ml-archive/attachments/20140729/1b53a492/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
> ------------------------------
>
> End of OmniOS-discuss Digest, Vol 28, Issue 8
> *********************************************
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140811/7e6d7951/attachment-0001.html>
More information about the OmniOS-discuss
mailing list