Messages in this thread | | | Date | Thu, 10 Jun 2004 17:15:41 +0200 | From | Jens Axboe <> | Subject | Re: ide errors in 7-rc1-mm1 and later |
| |
On Thu, Jun 10 2004, Chris Mason wrote: > On Wed, 2004-06-09 at 20:38, Andrew Morton wrote: > > Chris Mason <mason@suse.com> wrote: > > > > > > On Wed, 2004-06-09 at 19:50, Andrew Morton wrote: > > > > Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl> wrote: > > > > > > > > > > Does journal has checksum or some other protection against failure during > > > > > writing journal to a disk? If not than it still can be screwed even with > > > > > ordered writes if we are unfortunate enough. ;-) > > > > > > > > A transaction is written to disk as two synchronous operations: write all > > > > the data, wait on it, write the single commit block, wait on that. > > > > > > > > If the commit block were to hit disk before the data then we have a window > > > > in which poweroff+recovery would replay garbage into the filesystem. > > > > > > > > So I think we have a bug in the current ext3 barrier implementation - we > > > > need a blk_issue_flush() before submitting the buffer_ordered commit block. > > > > > > The IDE barriers are both a pre and post flush. If the commit block is > > > ordered, before the commit block hits the disk we know all the blocks > > > previously submitted are also on disk. > > > > > > > Oh, OK. Will the same apply to (for example) scsi? > > For scsi the general expectation is that write cache will be off unless > it is battery backed. blkdev_issue_flush does go down to scsi, but I'm > not sure about the regular WRITE_BARRIER stuff. Jens?
That's right, blkdev_issue_flush() works but barriers don't yet. The usual error handling story.
-- Jens Axboe
- 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/
| |