Date: Wed, 25 Mar 2009 13:55:28 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Mark Powell <M.S.Powell@salford.ac.uk> Cc: kevin <kevinxlinuz@163.com>, FreeBSD Current <freebsd-current@freebsd.org>, Daniel Eriksson <daniel@toomuchdata.com> Subject: Re: Apparently spurious ZFS CRC errors (was Re: ZFS data error without reasons) Message-ID: <20090325135528.21416hzpozpjst8g@webmail.leidinger.net> In-Reply-To: <20090325103721.G67233@rust.salford.ac.uk> 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> <20090325105613.55624rkkgf2xkr6s@webmail.leidinger.net> <20090325103721.G67233@rust.salford.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Mark Powell <M.S.Powell@salford.ac.uk> (from Wed, 25 Mar 2009 =20 10:45:43 +0000 (GMT)): > On Wed, 25 Mar 2009, Alexander Leidinger wrote: > >> Quoting Mark Powell <M.S.Powell@salford.ac.uk> (from Fri, 20 Mar =20 >> 2009 15:30:11 +0000 (GMT)): >>> 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 error= s. >>> I now need to find which option fixed it. >>> I suspect hw.ata.wc. Is this still a known issue? > > Alex, > Thanks for the input, > >> I would expect that it is the combination of cache_flush_disable =20 >> and zil_disable with the wc enable. If you reenable the zil and the =20 >> cache flush, the wc should not cause the problems you see. You may =20 >> want to have a look at =20 >> http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide for = a =20 >> more detailed description of what those options are doing (and why =20 >> you should not disable those features on normal disks). I also =20 >> suggest to not disable the meta-data compression, as it seems it =20 >> only affects a small amount of meta-data instead of all meta-data. > > I initially ran 8 with default options i.e. write caching on, all =20 > zfs options left enabled. I got the errors. Only then did I try =20 > changing options, by turning off wc and disabling zfs options. > It's a little curious that I should reenable the wc, and all zfs =20 > options except prefetch_disable. That takes me back to how I =20 > originally started, but with the solution to the problem therefore =20 > being disabling the prefetch. > Can prefetch really cause these problems? And if so why? I don't think so. I missed the part where you explained this before. =20 In this case it's really the write cache. The interesting questions is =20 if this is because of the harddisks you use, or because of a bug in =20 the software. You run a very recent current? 1-2 weeks before there was a bug (not =20 in ZFS) which caused CRC errors, but it was fixed shortly after it was =20 noticed. If you haven't updated your system, it may be best to update =20 it and try again. Please report back. >> 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, =20 >> it makes sense to have a high value when you have command queueing, =20 >> which we have with SCSI drives, but not yet with SATA drives and =20 >> probably not at all with PATA drives). > > I'm running completely SATA with NCQ supporting drives. However, and =20 > possibly as you say, NCQ is not really/properly supported in FBSD? NCQ is not supported yet in FreeBSD. Alexander Motin said he is =20 interested in implementing it, but I don't know about the status of =20 this. Bye, Alexander. --=20 Your business will assume vast proportions. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090325135528.21416hzpozpjst8g>