It does seem to be faster now that I really installed the non-debug bits. I let it resume a scrub after reboot, and while it's not as fast as it usually is (280 - 300 MB/s vs 500+) I assume it's just presently checking a part of the filesystem currently with smaller files thus reducing the speed, since it's well past the prior limitation. I tested 142 non-debug briefly until the scrub reached at least 250 MB/s and then booted into 145 non-debug where I'm letting the scrub finish now. I'll test the Nexanta disc again to be sure it was slow since I don't recall exactly how much time I gave it in my prior tests for the scrub to reach it's normal speed, although I can't do that until this evening when I'm home again.
Chad On Wed, Jul 21, 2010 at 09:44:42AM -0700, Chad Cantwell wrote: > Hi, > > My bits were originally debug because I didn't know any better. I thought I > had then > recompiled without debug to test again, but I didn't realize until just now > the packages > end up in a different directory (nightly vs nightly-nd) so I believe after > compiling > non-debug I just reinstalled the debug bits. I'm about to test again with an > actual > non-debug 142, and after that a non-debug 145 which just came out. > > Thanks, > Chad > > On Wed, Jul 21, 2010 at 02:21:51AM -0400, Richard Lowe wrote: > > > > I built in the normal fashion, with the CBE compilers > > (cc: Sun C 5.9 SunOS_i386 Patch 124868-10 2009/04/30), and 12u1 lint. > > > > I'm not subscribed to zfs-discuss, but have you established whether the > > problematic build is DEBUG? (the bits I uploaded were non-DEBUG). > > > > -- Rich > > > > Haudy Kazemi wrote: > > >>> Could it somehow not be compiling 64-bit support? > > >>> > > >>> > > >>> -- > > >>> Brent Jones > > >>> > > >> > > >> I thought about that but it says when it boots up that it is 64-bit, and > > >> I'm able to run > > >> 64-bit binaries. I wonder if it's compiling for the wrong processor > > >> optomization though? > > >> Maybe if it is missing some of the newer SSEx instructions the zpool > > >> checksum checking is > > >> slowed down significantly? I don't know how to check for this though > > >> and it seems strange > > >> it would slow it down this significantly. I'd expect even a non-SSE > > >> enabled > > >> binary to be able to calculate a few hundred MB of checksums per second > > >> for > > >> a 2.5+ghz processor. > > >> > > >> Chad > > > > > > Would it be possible to do a closer comparison between Rich Lowe's fast > > > 142 > > > build and your slow 142 build? For example run a diff on the source, > > > build > > > options, and build scripts. If the build settings are close enough, a > > > comparison of the generated binaries might be a faster way to narrow > > > things > > > down (if the optimizations are different then a resultant binary > > > comparison > > > probably won't be useful). > > > > > > You said previously that: > > >> 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. > > >> > > > Are these the same compiler versions Rich Lowe used? Maybe there is a > > > compiler optimization bug. Rich Lowe's build readme doesn't tell us which > > > compiler he used. > > > http://genunix.org/dist/richlowe/README.txt > > > > > >> 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 > > > > > > Another older compilation guide: > > > http://hub.opensolaris.org/bin/view/Community+Group+tools/building_opensolaris _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
