From patchwork Thu Jan 12 16:13:26 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Liu Bo X-Patchwork-Id: 9513525 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A4DDF601E5 for ; Thu, 12 Jan 2017 16:06:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 959DB285EB for ; Thu, 12 Jan 2017 16:06:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 8674E286DB; Thu, 12 Jan 2017 16:06:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1FDF6285EB for ; Thu, 12 Jan 2017 16:06:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750889AbdALQGD (ORCPT ); Thu, 12 Jan 2017 11:06:03 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:49909 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751209AbdALQGC (ORCPT ); Thu, 12 Jan 2017 11:06:02 -0500 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0CG5u93012276 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2017 16:05:56 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v0CG5tuZ018451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2017 16:05:56 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v0CG5tx8023510; Thu, 12 Jan 2017 16:05:55 GMT Received: from localhost.us.oracle.com (/10.211.47.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 12 Jan 2017 08:05:55 -0800 From: Liu Bo To: linux-btrfs@vger.kernel.org Cc: David Sterba Subject: [PATCH v2] Btrfs: fix btrfs_ordered_update_i_size to update disk_i_size properly Date: Thu, 12 Jan 2017 08:13:26 -0800 Message-Id: <1484237606-17576-1-git-send-email-bo.li.liu@oracle.com> X-Mailer: git-send-email 2.5.5 In-Reply-To: <1480628770-18848-1-git-send-email-bo.li.liu@oracle.com> References: <1480628770-18848-1-git-send-email-bo.li.liu@oracle.com> X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP btrfs_ordered_update_i_size can be called by truncate and endio, but only endio takes ordered_extent which contains the completed IO. while truncating down a file, if there are some in-flight IOs, btrfs_ordered_update_i_size in endio will set disk_i_size to @orig_offset that is zero. If truncating-down fails somehow, we try to recover in memory isize with this zero'd disk_i_size. Fix it by only updating disk_i_size with @orig_offset when btrfs_ordered_update_i_size is not called from endio while truncating down and waiting for in-flight IOs completing their work before recover in-memory size. Besides fixing the above issue, add an assertion for last_size to double check we truncate down to the desired size. Signed-off-by: Liu Bo --- v2: add comments to clarify why we should update disk_i_size in the truncate case. fs/btrfs/inode.c | 14 ++++++++++++++ fs/btrfs/ordered-data.c | 14 ++++++++++++-- 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 1cf8e20..a872628 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -4682,6 +4682,13 @@ int btrfs_truncate_inode_items(struct btrfs_trans_handle *trans, btrfs_free_path(path); + if (err == 0) { + /* only inline file may have last_size != new_size */ + if (new_size >= root->sectorsize || + new_size > root->fs_info->max_inline) + ASSERT(last_size == new_size); + } + if (be_nice && bytes_deleted > SZ_32M) { unsigned long updates = trans->delayed_ref_updates; if (updates) { @@ -5064,6 +5071,13 @@ static int btrfs_setsize(struct inode *inode, struct iattr *attr) if (ret && inode->i_nlink) { int err; + /* To get a stable disk_i_size */ + err = btrfs_wait_ordered_range(inode, 0, (u64)-1); + if (err) { + btrfs_orphan_del(NULL, inode); + return err; + } + /* * failed to truncate, disk_i_size is only adjusted down * as we remove extents, so it should represent the true diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c index b2d1e95..35277c5 100644 --- a/fs/btrfs/ordered-data.c +++ b/fs/btrfs/ordered-data.c @@ -982,8 +982,18 @@ int btrfs_ordered_update_i_size(struct inode *inode, u64 offset, } disk_i_size = BTRFS_I(inode)->disk_i_size; - /* truncate file */ - if (disk_i_size > i_size) { + /* + * truncate file. + * If ordered is not NULL, then this is called from endio and + * disk_i_size will be updated by either truncate itself or any + * in-flight IOs which are inside the disk_i_size. + * + * Because btrfs_setsize() may set i_size with disk_i_size if truncate + * fails somehow, we need to make sure we have a precise disk_i_size by + * updating it as usual. + * + */ + if (!ordered && disk_i_size > i_size) { BTRFS_I(inode)->disk_i_size = orig_offset; ret = 0; goto out;