aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorDave Kleikamp <shaggy@linux.vnet.ibm.com>2008-02-10 01:09:32 -0500
committerTheodore Ts'o <tytso@mit.edu>2008-02-10 01:09:32 -0500
commitc4e35e07af162ea4d642b1c6ffacbb63c3ed1804 (patch)
treec1f74ee04e54f705d0b18c947a2efa9eea8344a2
parent7fb5409df092589b86cc9412d926879cb572b7f0 (diff)
JBD2: Clear buffer_ordered flag for barried IO request on success
In JBD2 jbd2_journal_write_commit_record(), clear the buffer_ordered flag for the bh after barried IO has succeed. This prevents later, if the same buffer head were submitted to the underlying device, which has been reconfigured to not support barrier request, the JBD2 commit code could treat it as a normal IO (without barrier). This is a port from JBD/ext3 fix from Neil Brown. More details from Neil: Some devices - notably dm and md - can change their behaviour in response to BIO_RW_BARRIER requests. They might start out accepting such requests but on reconfiguration, they find out that they cannot any more. JBD2 deal with this by always testing if BIO_RW_BARRIER requests fail with EOPNOTSUPP, and retrying the write requests without the barrier (probably after waiting for any pending writes to complete). However there is a bug in the handling this in JBD2 for ext4 . When ext4/JBD2 to submit a BIO_RW_BARRIER request, it sets the buffer_ordered flag on the buffer head. If the request completes successfully, the flag STAYS SET. Other code might then write the same buffer_head after the device has been reconfigured to not accept barriers. This write will then fail, but the "other code" is not ready to handle EOPNOTSUPP errors and the error will be treated as fatal. Cc: Neil Brown <neilb@suse.de> Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com> Signed-off-by: Mingming Cao <cmm@us.ibm.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
-rw-r--r--fs/jbd2/commit.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
index c35bf16f44f4..a8173081f831 100644
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -148,6 +148,8 @@ static int journal_submit_commit_record(journal_t *journal,
148 barrier_done = 1; 148 barrier_done = 1;
149 } 149 }
150 ret = submit_bh(WRITE, bh); 150 ret = submit_bh(WRITE, bh);
151 if (barrier_done)
152 clear_buffer_ordered(bh);
151 153
152 /* is it possible for another commit to fail at roughly 154 /* is it possible for another commit to fail at roughly
153 * the same time as this one? If so, we don't want to 155 * the same time as this one? If so, we don't want to
@@ -166,7 +168,6 @@ static int journal_submit_commit_record(journal_t *journal,
166 spin_unlock(&journal->j_state_lock); 168 spin_unlock(&journal->j_state_lock);
167 169
168 /* And try again, without the barrier */ 170 /* And try again, without the barrier */
169 clear_buffer_ordered(bh);
170 set_buffer_uptodate(bh); 171 set_buffer_uptodate(bh);
171 set_buffer_dirty(bh); 172 set_buffer_dirty(bh);
172 ret = submit_bh(WRITE, bh); 173 ret = submit_bh(WRITE, bh);