On Mon, Jul 19, 2010 at 07:01:54PM -0700, Chad Cantwell wrote: > On Tue, Jul 20, 2010 at 10:54:44AM +1000, James C. McPherson wrote: > > On 20/07/10 10:40 AM, Chad Cantwell wrote: > > >fyi, everyone, I have some more info here. in short, rich lowe's 142 works > > >correctly (fast) on my hardware, while both my compilations (snv 143, snv > > >144) > > >and also the nexanta 3 rc2 kernel (134 with backports) are horribly slow. > > > > > >I finally got around to trying rich lowe's snv 142 compilation in place of > > >my own compilation of 143 (and later 144, not mentioned below), and unlike > > >my own two compilations, his works very fast again on my same zpool ( > > >scrubbing avg increased from low 100s to over 400 MB/s within a few > > >minutes after booting into this copy of 142. I should note that since > > >my original message, I also tried booting from a Nexanta Core 3.0 RC2 ISO > > >after realizing it had zpool 26 support backported into 134 and was in > > >fact able to read my zpool despite upgrading the version. Running a > > >scrub from the F2 shell on the Nexanta CD was also slow scrubbing, just > > >like the 143 and 144 that I compiled. So, there seem to be two > > >possibilities. > > >Either (and this seems unlikely) there is a problem introduced post-142 > > >which > > >slows things down, and it occured in 143, 144, and was brought back to 134 > > >with Nexanta's backports, or else (more likely) there is something > > >different > > >or wrong with how I'm compiling the kernel that makes the hardware not > > >perform up to its specifications with a zpool, and possibly the Nexanta 3 > > >RC2 ISO has the same problem as my own compilations. > > > > So - what's your env file contents, which closedbins are you using, > > why crypto bits are you using, and what changeset is your own workspace > > synced with? > > > > > > James C. McPherson > > -- > > Oracle > > http://www.jmcp.homeunix.com/blog > > > The procedure I followed was basically what is outlined here: > http://insanum.com/blog/2010/06/08/how-to-build-opensolaris > > using the SunStudio 12 compilers for ON and 12u1 for lint. > > For each build (143, 144) I cloned the exact tag for that build, i.e.: > > # hg clone ssh://a...@hg.opensolaris.org/hg/onnv/onnv-gate onnv-b144 > # cd onnv-b144 > # hg update onnv_144 > > Then I downloaded the corresponding closed and crypto bins from > http://dlc.sun.com/osol/on/downloads/b143 or > http://dlc.sun.com/osol/on/downloads/b144 > > The only environemnt variables I modified from the default opensolaris.sh > file were the basic ones: GATE, CODEMGR_WS, STAFFER, and ON_CRYPTO_BINS > to point to my work directory for the build, my username, and the relevant > crypto bin: > > $ egrep -e "^GATE|^CODEMGR_WS|^STAFFER|^ON_CRYPTO_BINS" opensolaris.sh > GATE=onnv-b144; export GATE > CODEMGR_WS="/work/compiling/$GATE"; export > CODEMGR_WS > STAFFER=chad; export STAFFER > ON_CRYPTO_BINS="$CODEMGR_WS/on-crypto-latest.$MACH.tar.bz2" > > I suppose the easiest way for me to confirm if there is a regression or if my > compiling is flawed is to just try compiling snv_142 using the same procedure > and see if it works as well as Rich Lowe's copy or if it's slow like my other > compilations. > > Chad >
I've just compiled and booted into snv_142, and I experienced the same slow dd and scrubbing as I did with my 142 and 143 compilations and with the Nexanta 3 RC2 CD. So, this would seem to indicate a build environment/process flaw rather than a regression. Chad _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
