2.4.x write barriers (updated for ext3)

Hi everyone,

I've changed the write barrier code around a little so the block layer isn't forced to fail barrier requests the queue can't handle.

This makes it much easier to add support for ide writeback flushing to things like ext3 and lvm, where I want to make the minimal possible changes to make things safe.

The full patch is at:
ftp.suse.com/pub/people/mason/patches/2.4.18/queue-barrier-8.diff

There might be additional spots in ext3 where ordering needs to be enforced, I've included the ext3 code below in hopes of getting some comments.

The only other change was to make reiserfs use the IDE flushing mode by default. It falls back to non-ordered calls on scsi.

-chris

@@ -595,7 +595,15 @@
                struct buffer_head *bh = jh2bh(descriptor);
                clear_bit(BH_Dirty, &bh->b_state);
                bh->b_end_io = journal_end_buffer_io_sync;
+
+               /* if we're on an ide device, setting BH_Ordered_Flush
+                  will force a write cache flush before and after the
+                  commit block.  Otherwise, it'll do nothing.  */
+
+               set_bit(BH_Ordered_Flush, &bh->b_state);
                submit_bh(WRITE, bh);
+               clear_bit(BH_Ordered_Flush, &bh->b_state);
+
                wait_on_buffer(bh);
                put_bh(bh);             /* One for getblk() */
                journal_unlock_journal_head(descriptor);

Hi,

Nice.

No. However, there is another optimisation which we can make.

Most ext3 commits, in practice, are lazy, asynchronous commits, and we only nedd BH_Ordered_Tag for that, not *_Flush. It would be easy enough to track whether a given transaction has any synchronous waiters, and if not, to use the async *_Tag request for the commit block instead of forcing a flush.

We'd also have to track the sync status of the most recent transaction, too, so that on fsync of a non-dirty file/inode, we make sure that its data had been forced to disk by at least one synchronous flush.

But that's really only a win for SCSI, where proper async ordered tags are supported. For IDE, the single BH_Ordered_Flush is quite sufficient.

Cheers,
Stephen

Just a note, the scsi code doesn't implement flush at all, flush either gets ignored or failed (if BH_Ordered_Hard is set), the assumption being that scsi devices don't write back by default, so wait_on_buffer() is enough.

The reiserfs code tries to be smart with _Tag, in pratice I haven't found a device that gains from it, so I didn't want to make the larger changes to ext3 until I was sure it was worthwhile ;-)

It seems the scsi drives don't do tag ordering as nicely as we'd hoped, I'm hoping someone with a big raid controller can help benchmark the ordered tag mode on scsi. Also, check the barrier threads from last week on how write errors might break the ordering with the current scsi code.

-chris