Re: [PATCH] 2.4.x write barriers (updated for ext3)

Chris Mason (mason@suse.com)
Thu, 28 Feb 2002 10:55:46 -0500


On Thursday, February 28, 2002 09:36:52 AM -0600 James Bottomley <James.Bottomley@steeleye.com> wrote:

> 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/