From patchwork Tue Mar 17 17:33:53 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Kara X-Patchwork-Id: 24573 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id E2631DDEF2 for ; Wed, 18 Mar 2009 06:44:11 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753656AbZCQTn5 (ORCPT ); Tue, 17 Mar 2009 15:43:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752468AbZCQTn5 (ORCPT ); Tue, 17 Mar 2009 15:43:57 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47321 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752190AbZCQTn4 (ORCPT ); Tue, 17 Mar 2009 15:43:56 -0400 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 8DF5B6B40C; Tue, 17 Mar 2009 19:12:08 +0100 (CET) Received: from duck.suse.cz (duck.suse.cz [10.20.1.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.suse.cz (Postfix) with ESMTP id 7A6B3628085; Tue, 17 Mar 2009 18:33:56 +0100 (CET) Received: by duck.suse.cz (Postfix, from userid 10005) id E166D251A79; Tue, 17 Mar 2009 18:33:55 +0100 (CET) From: Jan Kara To: LKML Cc: linux-ext4@vger.kernel.org, Jan Kara Subject: [PATCH 2/4] ext3: Avoid false EIO errors Date: Tue, 17 Mar 2009 18:33:53 +0100 Message-Id: <1237311235-13623-3-git-send-email-jack@suse.cz> X-Mailer: git-send-email 1.6.0.2 In-Reply-To: <1237311235-13623-2-git-send-email-jack@suse.cz> References: <1237311235-13623-1-git-send-email-jack@suse.cz> <1237311235-13623-2-git-send-email-jack@suse.cz> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Sometimes block_write_begin() can map buffers in a page but later we fail to copy data into those buffers (because the source page has been paged out in the mean time). We then end up with !uptodate mapped buffers. We must not file such buffers into a transaction - firstly they contain garbage and secondly it confuses the journaling code (it thinks write has failed and complains about IO errors). Signed-off-by: Jan Kara --- fs/ext3/inode.c | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/fs/ext3/inode.c b/fs/ext3/inode.c index 62005c0..d351eab 100644 --- a/fs/ext3/inode.c +++ b/fs/ext3/inode.c @@ -1430,7 +1430,11 @@ static int bput_one(handle_t *handle, struct buffer_head *bh) static int journal_dirty_data_fn(handle_t *handle, struct buffer_head *bh) { - if (buffer_mapped(bh)) + /* + * Parallel write could have mapped the buffer but it didn't copy + * the data in yet. So avoid filing such buffer into a transaction. + */ + if (buffer_mapped(bh) && buffer_uptodate(bh)) return ext3_journal_dirty_data(handle, bh); return 0; }