[OmniOS-discuss] announcement znapzend
Tobias Oetiker
tobi at oetiker.ch
Tue Aug 12 05:54:08 UTC 2014
Hi Theo,
znapzend can use mbuffers ability to do a direct tcp connection to another
mbuffer instance ...
didn't know about pv though ... neat tool!
cheers
tobi
http://www.znapzend.org
Yesterday Theo Schlossnagle wrote:
> 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
> >
>
>
>
>
--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
www.oetiker.ch tobi at oetiker.ch +41 62 775 9902
More information about the OmniOS-discuss
mailing list