Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4285408pxv; Mon, 5 Jul 2021 19:34:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzYQ1JG2NnytV5BQwY9Fr6Q0XAvfXHC9tstngJ6lNRZvGuxDAub6bQ46bFDJBbIewKh7qcf X-Received: by 2002:a05:6e02:1d12:: with SMTP id i18mr13028922ila.97.1625538887643; Mon, 05 Jul 2021 19:34:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625538887; cv=none; d=google.com; s=arc-20160816; b=MPirnrBgSANvtWfORRi53RgHIjabALNk6aqeaF2KY97r1yGI1h4OlQ7aR8H7vKEc5f 9NlXVCAS2XwXFbimva+IFSS0t6lI3+sBB+byDAuZwMN/YXKGfSauPieBOz909JSYE3/Q QNwH/5Go9Wz2LW6TXmbW5pwdojKrBHsY2488PlawGX2KgMjYhws5uMZc0lZYcplCcpZq UWVYeWYrtnfa5qTSx3SbOVClLIXWecOLhcbbgkwtwJCdySLhP4HFxDC3XFDi1yLZmpYo 6ze3Nh9aJtYzPsMBGwI6Vcn3UBnrza5hc0raFwQgb4HDLKuP/XKJ+/3oCWsGBA5wIP9+ 48MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=k0v9lS0mVNlSLAiluIWIedhH5FhlTJm3MjieeLFX15E=; b=l9iMZmDSqDPO2kXZaIyE50YkOkqspyqiGok+7OLIlXf51TsEwkU/3mgPW+FQ0U1yyX qKnfS/7F04UFFVjjrEHsrEp/qhWYRv/CQazeggFHEMRd4c9+EcoZESD8KaTnvTZkmUxJ njT3ZhxWmTSYV5u9etSMMWy1zhln2HKg7d2IudpcdOWWGQCNz4HKb+EkBkK/bNjuixhJ 5nXFHVJ3pObgdfQGmF2wrol9J/jv44+4PpA7isSlnJM7/3ibCJSHgLNTCP1XVzt0YHYK /9JwcgLK6HmgOLokTyvxD4J/zHTxx6IwnBg4SeqyM/5UNFak9cDJ0PUEs04dfSF+ADld m96A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z12si17325973iow.31.2021.07.05.19.34.30; Mon, 05 Jul 2021 19:34:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229947AbhGFCgY (ORCPT + 99 others); Mon, 5 Jul 2021 22:36:24 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:13081 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229935AbhGFCgY (ORCPT ); Mon, 5 Jul 2021 22:36:24 -0400 Received: from dggeme752-chm.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4GJmkK6V7ZzZnFJ; Tue, 6 Jul 2021 10:30:33 +0800 (CST) Received: from huawei.com (10.175.127.227) by dggeme752-chm.china.huawei.com (10.3.19.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 6 Jul 2021 10:33:44 +0800 From: Zhang Yi To: CC: , , , , Subject: [RFC PATCH 1/4] ext4: check and update i_disksize properly Date: Tue, 6 Jul 2021 10:42:07 +0800 Message-ID: <20210706024210.746788-2-yi.zhang@huawei.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210706024210.746788-1-yi.zhang@huawei.com> References: <20210706024210.746788-1-yi.zhang@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggeme752-chm.china.huawei.com (10.3.19.98) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org After commit 3da40c7b0898 ("ext4: only call ext4_truncate when size <= isize"), i_disksize could always be updated to i_size in ext4_setattr(), and it seems that there is no other way that could appear i_disksize < i_size besides the delalloc write. In the case of delay alloc write, ext4_writepages() could update i_disksize for the new delay allocated blocks properly. So we could switch to check i_size instead of i_disksize in ext4_da_write_end() when write to the end of the file. we also could remove ext4_mark_inode_dirty() together because generic_write_end() will dirty the inode. Signed-off-by: Zhang Yi --- fs/ext4/inode.c | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index d8de607849df..6f6a61f3ae5f 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3087,32 +3087,27 @@ static int ext4_da_write_end(struct file *file, * generic_write_end() will run mark_inode_dirty() if i_size * changes. So let's piggyback the i_disksize mark_inode_dirty * into that. + * + * Check i_size not i_disksize here because ext4_writepages() could + * update i_disksize from i_size for delay allocated blocks properly. */ new_i_size = pos + copied; - if (copied && new_i_size > EXT4_I(inode)->i_disksize) { + if (copied && new_i_size > inode->i_size) { if (ext4_has_inline_data(inode) || - ext4_da_should_update_i_disksize(page, end)) { + ext4_da_should_update_i_disksize(page, end)) ext4_update_i_disksize(inode, new_i_size); - /* We need to mark inode dirty even if - * new_i_size is less that inode->i_size - * bu greater than i_disksize.(hint delalloc) - */ - ret = ext4_mark_inode_dirty(handle, inode); - } } if (write_mode != CONVERT_INLINE_DATA && ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) && ext4_has_inline_data(inode)) - ret2 = ext4_da_write_inline_data_end(inode, pos, len, copied, + ret = ext4_da_write_inline_data_end(inode, pos, len, copied, page); else - ret2 = generic_write_end(file, mapping, pos, len, copied, + ret = generic_write_end(file, mapping, pos, len, copied, page, fsdata); - copied = ret2; - if (ret2 < 0) - ret = ret2; + copied = ret; ret2 = ext4_journal_stop(handle); if (unlikely(ret2 && !ret)) ret = ret2; -- 2.31.1