Date: Sat, 26 Nov 2005 15:07:02 -0500 (EST) From: user <user@dhp.com> To: Herve Boulouis <amon@sockar.homeip.net> Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) Message-ID: <Pine.LNX.4.21.0511261503030.8180-100000@shell.dhp.com> In-Reply-To: <20051126194152.GA594@ra.aabs>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 26 Nov 2005, Herve Boulouis wrote: > Le 26/11/2005 14:17, user a écrit: > > > > Read caching: yes/no (default is yes) > > > > (read caching does not rely on a battery, and is completely "safe", > > right? I am going to set this to "yes", however I wonder - why would > > anyone _ever_ set it to "no" ?) > > You usually want to disable read caching on all aac based adaptec raid > controllers because it decreases performance. Thanks - I did not know that, and that is good to know. > > Write caching: enable/disable > > > > (this is the one that can get you into trouble if the system loses power > > before a write is committed to disk, and the battery is dead, right? I am > > going to set this to "disable" because I do not think the 2610SA has a > > battery ... right ?) > > If your server is plugged on a UPS you can safely enable it, it's quite > a performance gain. Ok. It is. However, my experience has been that no matter how rock solid the datacenter provided, UPS backed power is, there is a power interruption about every 1-2 years (and this experience comes from very very good datacenters - from Level3 to UUnet, etc.) ... so ... let's say I bank on this and enable write caching, how big of a deal is it when that power interruption does come ? Assuming freebsd 6.0 and UFS2 ... is it just an fsck, or is there a potential for some real problems if the kernel thinks something is totally committed, but it never makes it to the drive ? > > Rebuild rate: high/medium/low > > > > (I have no idea what this means - I never saw this in adaptec bios before > > ... can anyone define exactly what this means ?) > > This controls how much ressources the card will put in rebuilding a volume > that got a failed disk. A high rebuild rate will mean a short rebuild time > but slower disk accesses during the rebuild. I am going to set it to "low" then ... my experience is that a failed disk often rebuilds itself only to re-fail shortly thereafter, thus making possible a continuous loop of rebuilding over and over ... which would essentially take the system offline if all resources were dedicated to the rebuild. Comments ? thanks very much.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0511261503030.8180-100000>