> Doug Gilbert prompted me to re-examine my notions about SCSI drive caching,
> and sure enough the standard says (and all the drives I've looked at so far
> come with) write back caching enabled by default.
Really. Has it always been this way?
>
> Since this is a threat to the integrity of Journalling FS in power failure
> situations now, I think it needs to be addressed with some urgency.
>
> The "quick fix" would obviously be to get the sd driver to do a mode select at
> probe time to turn off the WCE and RCD bits (this will place the cache into
> write through mode), which would match the assumptions all the JFSs currently
> make. I'll see if I can code up a quick patch to do this.
Ok.
>
> A longer term solution might be to keep the writeback cache but send down a
> SYNCHRONIZE CACHE command as part of the back end completion of a barrier
> write, so the fs wouldn't get a completion until the write was done and all
> the dirty cache blocks flushed to the medium.
Right, they could just implement ORDERED_FLUSH in the barrier patch.
>
> Clearly, there would also have to be a mechanism to flush the cache on
> unmount, so if this were done by ioctl, would you prefer that the filesystem
> be in charge of flushing the cache on barrier writes, or would you like the sd
> device to do it transparently?
How about triggered by closing the block device. That would also cover
people like oracle that do stuff to the raw device.
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/