On 14 Dec 2017, at 14:43, O. Hartmann <ohartm...@walstatt.org> wrote: > > Am Thu, 14 Dec 2017 14:09:39 +0100 > Daniel Nebdal <dneb...@gmail.com> schrieb: >> On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann <ohartm...@walstatt.org> wrote: >>> I just started the rebuild/resilvering process and watch the pool crwaling >>> at ~ 18 >>> MB/s. At the moment, there is no load on the array, the host is a IvyBridge >>> XEON with >>> 4 core/8 threads and 3,4 GHz and 16 GB of RAM. The HDDs are attached to a >>> on-board >>> SATA II (300 MB/s max) Intel chip - this just for the record. >>> >>> Recently, I switch on the "sync" attribute on most of the defined pools's >>> zfs >>> filesystems >>> - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused >>> recently in >>> FreeBSD CURRENT's ZFS - this from a observers perspective only. >>> >>> When scrubbing, I see recently also reduced performance on the pool, so I'm >>> wondering >>> about the low throughput at the very moment when resilvering is in progress. >>> >>> If the "perspective" of "zpool status" is correct, then I have to wait >>> after two hours >>> for another 100 hours - ~ 4 days? Ups ... I think there is something badly >>> misconfigured or missing. ... >> This is kind of to be expected - for whatever reason, resilvers seem >> to go super slow at first and then speed up significantly. Just don't >> ask me how long "at first" is - I'd give it several (more) hours.
Hopefully this will get better in the future, please read: http://open-zfs.org/wiki/Scrub/Resilver_Performance -Dimitry
signature.asc
Description: Message signed with OpenPGP
