scrub completed after 1h9m with 0 errors on Tue Feb 17 12:09:31 2009 This is about twice as slow as the same srub on a solaris 10 box with a mirrored zfs root pool. Has scrub become that much slower? And if so, why? -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D + http://nagual.nl/ | SunOS sxce snv107 ++ + All that''s really worth doing is what we do for others (Lewis Carrol)
Do you have more data on the 107 pool than on the sol10 pool? On Tue, Feb 17, 2009 at 6:11 AM, dick hoogendijk <dick at nagual.nl> wrote:> scrub completed after 1h9m with 0 errors on Tue Feb 17 12:09:31 2009 > > This is about twice as slow as the same srub on a solaris 10 box with a > mirrored zfs root pool. Has scrub become that much slower? And if so, > why? > > -- > Dick Hoogendijk -- PGP/GnuPG key: 01D2433D > + http://nagual.nl/ | SunOS sxce snv107 ++ > + All that''s really worth doing is what we do for others (Lewis Carrol) > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
On Tue, 17 Feb 2009 08:41:13 -0500 Blake <blake.irvin at gmail.com> wrote:> Do you have more data on the 107 pool than on the sol10 pool?80G on the "fast" one and 85G on the slow one. Furthermore, on the fast one the total amount is 100G more than on the slow one. So, I don''t get it ;-) -- Dick Hoogendijk -- PGP/GnuPG key: 01D2433D + http://nagual.nl/ | SunOS sxce snv107 ++ + All that''s really worth doing is what we do for others (Lewis Carrol)
On 17 February, 2009 - dick hoogendijk sent me these 0,6K bytes:> On Tue, 17 Feb 2009 08:41:13 -0500 > Blake <blake.irvin at gmail.com> wrote: > > > Do you have more data on the 107 pool than on the sol10 pool? > > 80G on the "fast" one and 85G on the slow one. > Furthermore, on the fast one the total amount is 100G more than on the > slow one. So, I don''t get it ;-)The number of files also matter, as ZFS goes through the filesystem for scrub/resilver.. A filesystem with 10x10G files scrubs faster than one with 10000000x10k files.. /Tomas -- Tomas ?gren, stric at acc.umu.se, http://www.acc.umu.se/~stric/ |- Student at Computing Science, University of Ume? `- Sysadmin at {cs,acc}.umu.se
>On 17 February, 2009 - dick hoogendijk sent me these 0,6K bytes: > >> On Tue, 17 Feb 2009 08:41:13 -0500 >> Blake <blake.irvin at gmail.com> wrote: >>=20 >> > Do you have more data on the 107 pool than on the sol10 pool? >>=20 >> 80G on the "fast" one and 85G on the slow one. >> Furthermore, on the fast one the total amount is 100G more than on >the >> slow one. So, I don''t get it ;-) > >The number of files also matter, as ZFS goes through the filesystem f>or >scrub/resilver.. > >A filesystem with 10x10G files scrubs faster than one with 10000000x1>0k files..I currently have a system with 2x1TB WDC disks; it''s now running 103 and I hope to upgrade it to 108 or 109 shortly. Then we should be able to measure between a build before and after 105. It only uses around 200GB and it now takes around 1 hour to "scrub" it. Casper
Casper.Dik at Sun.COM wrote:> I currently have a system with 2x1TB WDC disks; it''s now running 103 and I > hope to upgrade it to 108 or 109 shortly. Then we should be able to > measure between a build before and after 105. > > It only uses around 200GB and it now takes around 1 hour to "scrub" it.I have a nv_102 system with 2 mirrored 500GB data drives, 362GB used, and that takes 12 hours to scrub. My subjective impression is that back around build 70-something, it was very much faster to scrub, but left the system almost completely unusable whilst doing so. The impact of the scrub on the system performance is now less disruptive. Usage of the system has changed over this period, so it''s difficult to be sure what''s responsible for what changes, but the increase in the scrub time certainly is significant. The other thing that''s changed over that period is that it grows 7 extra snapshots/day, and now has 2700 snapshots - I don''t know if number of snapshots has any impact. I would like to be able to pause and resume scrubs, so as to run them only when system isn''t being otherwise used. (RFE 6730306) -- Andrew