From patchwork Mon Mar 5 07:49:36 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lukas Czerner X-Patchwork-Id: 144617 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.180.67]) by ozlabs.org (Postfix) with ESMTP id E3ED0B6EEE for ; Mon, 5 Mar 2012 18:49:49 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755504Ab2CEHtr (ORCPT ); Mon, 5 Mar 2012 02:49:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9842 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755485Ab2CEHtq (ORCPT ); Mon, 5 Mar 2012 02:49:46 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q257njR5020756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Mar 2012 02:49:45 -0500 Received: from dhcp-27-109.brq.redhat.com (vpn1-7-111.ams2.redhat.com [10.36.7.111]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q257ncN0029625; Mon, 5 Mar 2012 02:49:44 -0500 From: Lukas Czerner To: linux-ext4@vger.kernel.org Cc: tytso@mit.edu, sandeen@redhat.com, Lukas Czerner Subject: [PATCH 4/4] e2fsck: Do not discard itable if discard doen't zero data Date: Mon, 5 Mar 2012 08:49:36 +0100 Message-Id: <1330933776-2696-4-git-send-email-lczerner@redhat.com> In-Reply-To: <1330933776-2696-1-git-send-email-lczerner@redhat.com> References: <1330933776-2696-1-git-send-email-lczerner@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org We do not want to discard inode table if the underlying device does not return zeros when reading non-provisioned blocks. The reason is that if the inode table is not zeroed yet, then discard would not help us since we would have to zero it anyway. In the case that inode table was already zeroed, then the discard would cause subsequent reads to contain non-deterministic data so we would not be able to assume that the inode table was zeroed and we would need to zero it again, which does not really make sense. This commit adds check to prevent inode table from being discarded if the discard does not zero data. Signed-off-by: Lukas Czerner Reviewed-by: Eric Sandeen --- e2fsck/pass5.c | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/e2fsck/pass5.c b/e2fsck/pass5.c index 741e6dd..9e63037 100644 --- a/e2fsck/pass5.c +++ b/e2fsck/pass5.c @@ -116,7 +116,18 @@ static void e2fsck_discard_inodes(e2fsck_t ctx, int group, ctx->options &= ~E2F_OPT_DISCARD; } - if (!(ctx->options & E2F_OPT_DISCARD)) + /* + * Do not attempt to discard if E2F_OPT_DISCARD is not set. And also + * skip the discard on this group if discard does not zero data. + * The reason is that if the inode table is not zeroed discard would + * no help us since we need to zero it anyway, or if the inode table + * is zeroed then the read after discard would not be deterministic + * anyway and we would not be able to assume that this inode table + * was zeroed anymore so we would have to zero it again, which does + * not really make sense. + */ + if (!(ctx->options & E2F_OPT_DISCARD) || + !io_channel_discard_zeroes_data(fs->io)) return; /*