> Doesn't this mean that if you enable write back, and you have > a single, non-mirrored raid-controller, and your raid controller > dies on you so that you loose the contents of the nvram, you have > a potentially corrupt file system?
It is understood, that any single point of failure could result in failure, yes. If you have a CPU that performs miscalculations, makes mistakes, it can instruct bad things to be written to disk (I've had something like that happen before.) If you have RAM with bit errors in it that go undetected, you can have corrupted memory, and if that memory is destined to write to disk, you'll have bad data written to disk. If you have a non-redundant raid controller, which buffers writes, and the buffer gets destroyed or corrupted before the writes are put to disk, then the data has become corrupt. Heck, the same is true even with redundant raid controllers, if there are memory errors in one that go undetected. So you'll have to do your own calculation. Which is worse? - Don't get the benefit of accelerated hardware, for all the time that the hardware is functioning correctly, Or - Take the risk of acceleration, with possibility the accelerator could fail and cause harm to the data it was working on. I know I always opt for using the raid write-back. If I ever have a situation where I'm so scared of the raid card corrupting data, I would be equally scared of the CPU or SAS bus or system ram or whatever. In that case, I'd find a solution that makes entire machines redundant, rather than worrying about one little perc card. Yes it can happen. I've seen it happen. But not just to raid cards; everything else is vulnerable too. I'll take a 4x performance improvement for 99.999% of the time, and risk the corruption the rest of the time. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
