Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c4e35e07af162ea4d642b1c6ffacbb63c3ed1804
Commit:     c4e35e07af162ea4d642b1c6ffacbb63c3ed1804
Parent:     7fb5409df092589b86cc9412d926879cb572b7f0
Author:     Dave Kleikamp <[EMAIL PROTECTED]>
AuthorDate: Sun Feb 10 01:09:32 2008 -0500
Committer:  Theodore Ts'o <[EMAIL PROTECTED]>
CommitDate: Sun Feb 10 01:09:32 2008 -0500

    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 <[EMAIL PROTECTED]>
    Signed-off-by: Dave Kleikamp <[EMAIL PROTECTED]>
    Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
    Signed-off-by: "Theodore Ts'o" <[EMAIL PROTECTED]>
---
 fs/jbd2/commit.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
index c35bf16..a817308 100644
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -148,6 +148,8 @@ static int journal_submit_commit_record(journal_t *journal,
                barrier_done = 1;
        }
        ret = submit_bh(WRITE, bh);
+       if (barrier_done)
+               clear_buffer_ordered(bh);
 
        /* is it possible for another commit to fail at roughly
         * 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,
                spin_unlock(&journal->j_state_lock);
 
                /* And try again, without the barrier */
-               clear_buffer_ordered(bh);
                set_buffer_uptodate(bh);
                set_buffer_dirty(bh);
                ret = submit_bh(WRITE, bh);
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to