Messages in this thread | | | Date | Thu, 28 Feb 2002 10:55:46 -0500 | From | Chris Mason <> | Subject | Re: [PATCH] 2.4.x write barriers (updated for ext3) |
| |
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/
| |