Date: Tue, 12 Oct 2004 11:44:39 -0700 From: Roisin Murphy <Roisin.Murphy@gmail.com> To: "Kenneth D. Merry" <ken@freebsd.org> Cc: freebsd-hardware@freebsd.org Subject: Re: sata raid & write cache state Message-ID: <b21e6cca0410121144420fe03b@mail.gmail.com> In-Reply-To: <20041012171106.GB86646@nargothrond.kdm.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 :) > 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? 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+
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b21e6cca0410121144420fe03b>