Date: Tue, 12 Oct 2004 15:59:51 -0600 From: "Kenneth D. Merry" <ken@freebsd.org> To: Roisin Murphy <Roisin.Murphy@gmail.com> Cc: freebsd-hardware@freebsd.org Subject: Re: sata raid & write cache state Message-ID: <20041012215951.GA89335@nargothrond.kdm.org> In-Reply-To: <b21e6cca0410121144420fe03b@mail.gmail.com> References: <b21e6cca041010181932879aeb@mail.gmail.com> <20041011043508.GA72113@nargothrond.kdm.org> <b21e6cca041011090816a1352@mail.gmail.com> <20041011210303.GA78436@nargothrond.kdm.org> <b21e6cca04101117425d2908eb@mail.gmail.com> <20041012171106.GB86646@nargothrond.kdm.org> <b21e6cca0410121144420fe03b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 12, 2004 at 11:44:39 -0700, Roisin Murphy wrote: > > The main point of write back caching is to give the user faster turnaround > > for their commands without the application having to support deep queueing. > > 1. that is now taken care of by the 'write back' cache on the raid > controller. So (s)ata raid setups can still perform similarly to scsi > setups. But enough about that :) > anyway, enough of that :) They can only perform similarly if they use a non-broken queueing model. See my other mail. Basically it'll require a drive and RAID controller that support SATA II Native Command Queueing, out of order completion, etc. > > Sure, you can recover from a power outage, you just have to scrub the array > > when you come back up. You also won't know for sure whether you have some > > data corruption. > > 2. how do you usually 'scrub' the array? is this automatically done by > the controller when it boots up? or does this usually require the user > issuing commands via those raid CLIs? A "scrub" means that the controller regenerates the parity on the array. So it goes through, reads the data chunks for each stripe, recalculates the parity, and writes the parity back out. The main difference between a scrub and a verify on a RAID-5 array is that the controller will generally tell you if there was an inconsistency on a verify. (So it has to read back the parity that is already on disk and compare it with the parity it calculated. I suppose it could also avoid writing the parity again on a verify if the old and new parity match.) If your machine crashes, the controller will generally automatically initiate a scrub if you don't have battery backed RAM or if your RAM isn't valid. With some controllers, you can issue commands via a CLI. (e.g. you can do it with Adaptec controllers that use the aac(4) driver.) > 3. one more thing about the battery back up option, now that i thought > about it, it has to be like a mini PSU that has enough power to keep > all the disks spinning for couple seconds after your main psu/power > dies, so now i understand why it cost $100+ Head to www.apc.com and look at the UPSes they have there. They're basically lead acid batteries with inverters to put out A/C power when your main power feed goes out. Ken -- Kenneth Merry ken@FreeBSD.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041012215951.GA89335>