On Wed, 2005-06-15 at 11:11 -0500, Brian King wrote: > System crash and controlled power off are two different things. Yes, if the > adapter is not told about the shutdown so it can flush its cache, the > data will be maintained, but it can only be maintained for as long as > the battery lasts. Currently, with 2.6.12-rc, if you do a normal power off > and leave the system powered off for a long enough period of time (usually > a week or so, depending on the battery on the card), you will suffer data > loss. This is not acceptable. With 2.6.11, the adapter is told to flush > the write cache on a controlled power off, so the system can remain powered > off indefinitely with no data loss. > > Regarding supporting the sync cache command to a disk array, I did consider > requesting support be added to the adapter microcode, but decided against it > since it would make a RAID array perform horribly and it did not seem to be > the appropriate model to follow for NV write cache. Some of the ipr adapters > have over 500 MB of write cache, which can take an awful long time to flush, > much longer than you would want for a journal barrier. So, all the barrier/ > SYNC_CACHE code works great for a volatile write cache on a disk, but > doesn't necessarily seem like the best model for large non-volatile write > caches for RAID adapters. Well, I still think you're operating unsafely ... some people let these batteries run out, you know ... To fix this, add a blk_queue_ordered(sdev->request_queue, QUEUE_ORDERED_NONE); to the slave configure routine for each of the devices that doesn't synchronize the cache. That should correct the SCSI layer assumptions. James - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
