Date: Mon, 11 Oct 2004 07:05:05 -0700 From: Roisin Murphy <Roisin.Murphy@gmail.com> To: freebsd-hardware@freebsd.org Subject: sata raid & write cache state&In-Reply-To=b21e6cca041010181932879aeb@mail.gmail.com Message-ID: <b21e6cca04101107058b003c9@mail.gmail.com> In-Reply-To: <20041011043508.GA72113@nargothrond.kdm.org> References: <b21e6cca041010181932879aeb@mail.gmail.com> <20041011043508.GA72113@nargothrond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
thanks for your response well, i'm not really concerned with read/write performance or with loosing little bit of cached data that the controller didn't manage to write down in a case of a power outage or anything breaking in the box. I don't plan to store anything critical. It will be used to dump lots of uncompressed pictures and video, but still the performance doesn't matter. The only thing i want to avoid is an inconsistent state of the array (=dead raid), if anything breaks in the box, and the actual disks&parity are not in sync. From what ken mentioned, it seems like ata/sata is a loose specification, and even if some sata disks do support tagged queueing, the controller most likely won't use it. So my best bet would be to get those floppy manufacturer utilities and set the write cache default to off on all the disks. > Well, any decent SCSI RAID controller will either just disable the write > cache altogether, or it will give the user the option of disabling the > write cache. > Of course a battery backed cache is useless if write caching is turned on > on your drives. So it will be a useless feature with most ATA or SATA RAID > controllers, because it's unlikely that they would want to tank their > performance badly by disabling write caching. 1. So if scsi controllers most likely switch the disk caches off, and optimize the writes with it's own on-board cache, why wouldn't a better/smarter ata/sata controller be able to do the same? I mean, how does a sata disk with cache off differ from a scsi disk with it's cache off? > Also, keep in mind that with any RAID controller that does RAID-5 or > RAID-1, you should get a battery backed cache. It may be an option, but > you should get it. This will protect you from the RAID-5/RAID-1 write > hole. That is, when you have a crash, you don't know: > 1. What writes you have outstanding. > 2. Whether all, part, or none of those writes got committed. 2. So the backup battery (the intel raid card has that option too), is that primarily meant to save the data from the controller's cache? Without the backup battery, could you still end up with an inconsistent/dead array? > So without a battery backed cache, you will have to scrub your entire > array to make sure the parity is consistent, and you still will not know > whether some of your data was corrupted. All you can really do is sync the > parity. 3. I would assume that this parity syncing will be automatic, or not necessary at all. Isn't the controller acting kind of like a transactional db, so even if the machine crashes in any way, the array still survives in a consistent state, only loosing the last active writes? So yes, you could end up with a corrupted file or two, but not with an inconsistent parity/dead array? and with battery backed up controller, you could avoid it altogether, unless the actual controller breaks? 4. Is any software raid solution able to deliver a safe raid5 setup? cache off on all the disks is a must of course. Anybody has a successful story with software solutions, proven by simulated crashes? :) All i keep hearing about vinum is 'not for production use'/'horror stories'
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b21e6cca04101107058b003c9>