Re: ide errors in 7-rc1-mm1 and later

[Jens Axboe <axboe@suse.de>]

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