From owner-freebsd-current@FreeBSD.ORG Wed Mar 25 09:56:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72F5B10656BC for ; Wed, 25 Mar 2009 09:56:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 1A5BA8FC0C for ; Wed, 25 Mar 2009 09:56:29 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2D310.dip.t-dialin.net [217.226.211.16]) by redbull.bpaserver.net (Postfix) with ESMTP id 0C0292E0A5; Wed, 25 Mar 2009 10:56:25 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 942BC204088; Wed, 25 Mar 2009 10:56:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1237974977; bh=wkF49RwHPsvwwQ4kXovLH4n7Q/ywMRF9e 4AdQPe+6p8=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HM7Q0/xL1JZJ/6AFwOsBSPXBRM1lB7ha5BQR3RizbpQgCFPakBiLFQdwhoW/cFIsa al4QnqEBwGJQ55pM5zPV2fHEvJqy1RPB6T1umJpr/PMvgL5vb57T2/QZgT5gb5pJY4Z yNoMjznNm3VKMk5c9dMQ15VhwSnCUywVBtQZ5WxlpviajWhbByVt10fbz0X1f5Wq6v8 eaKOo2EKZECshgpku0fgKvmThzmigkfEN5SX6+J5Vd8yMAFuX490FLhMES6+d14r4tQ qccxTEqNV8Xano26B9FA7vdKQejpZEtsB/TGrPSQav79h9Z85WPJIXXcXRRJrn0KkTq Hdma+nN4A== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n2P9uFUx029225; Wed, 25 Mar 2009 10:56:15 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Wed, 25 Mar 2009 10:56:13 +0100 Message-ID: <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 25 Mar 2009 10:56:13 +0100 From: Alexander Leidinger To: Mark Powell References: <49BD117B.2080706@163.com> <4F9C9299A10AE74E89EA580D14AA10A635E68A@royal64.emp.zapto.org> <49BE4EC1.90207@163.com> <20090320102824.W75873@rust.salford.ac.uk> <20090320152737.D641@rust.salford.ac.uk> In-Reply-To: <20090320152737.D641@rust.salford.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 0C0292E0A5.1BAEC X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.223, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, J_CHICKENPOX_37 0.60, RDNS_DYNAMIC 0.10, TW_ZF 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: kevin , FreeBSD Current , Daniel Eriksson Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 09:56:30 -0000 Quoting Mark Powell (from Fri, 20 Mar 2009 =20 15:30:11 +0000 (GMT)): > On Fri, 20 Mar 2009, Mark Powell wrote: > >> As this same hardware worked, well with 7 for a long time, and can =20 >> work perfectly with 8 for several days until the errors strike, =20 >> this seems like some curious 8 problem? > > Hmmm. Perhaps I'm not being fair on 8. Just had a look at my =20 > loader.conf for 7 and I can see that I used to run with every =20 > zfs*disable on. I've just rebooted 8 with: > > vfs.zfs.cache_flush_disable: 1 > vfs.zfs.mdcomp_disable: 1 > vfs.zfs.prefetch_disable: 1 > vfs.zfs.zil_disable: 1 > hw.ata.wc: 1 > > The current fs which produced errors on every scrub now reports no errors. > I now need to find which option fixed it. > I suspect hw.ata.wc. Is this still a known issue? I would expect that it is the combination of cache_flush_disable and =20 zil_disable with the wc enable. If you reenable the zil and the cache =20 flush, the wc should not cause the problems you see. You may want to =20 have a look at =20 http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide =20 for a more detailed description of what those options are doing (and =20 why you should not disable those features on normal disks). I also =20 suggest to not disable the meta-data compression, as it seems it only =20 affects a small amount of meta-data instead of all meta-data. If you want to get more out of zfs, maybe vfs.zfs.vdev.max_pending =20 could help if you are using SATA (as I read the zfs tuning guide, it =20 makes sense to have a high value when you have command queueing, which =20 we have with SCSI drives, but not yet with SATA drives and probably =20 not at all with PATA drives). Bye, Alexander. --=20 QOTD: =09"I am not sure what this is, but an 'F' would only dignify it." http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137