Quoting Mark Powell <M.S.Powell_at_salford.ac.uk> (from Fri, 20 Mar 2009 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 >> work perfectly with 8 for several days until the errors strike, >> this seems like some curious 8 problem? > > Hmmm. Perhaps I'm not being fair on 8. Just had a look at my > loader.conf for 7 and I can see that I used to run with every > 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 zil_disable with the wc enable. If you reenable the zil and the cache flush, the wc should not cause the problems you see. You may want to have a look at http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide for a more detailed description of what those options are doing (and why you should not disable those features on normal disks). I also suggest to not disable the meta-data compression, as it seems it only 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 could help if you are using SATA (as I read the zfs tuning guide, it makes sense to have a high value when you have command queueing, which we have with SCSI drives, but not yet with SATA drives and probably not at all with PATA drives). Bye, Alexander. -- QOTD: "I am not sure what this is, but an 'F' would only dignify it." http://www.Leidinger.net Alexander _at_ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild _at_ FreeBSD.org : PGP ID = 72077137Received on Wed Mar 25 2009 - 08:56:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:44 UTC