From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 42652ECAAD1 for ; Thu, 1 Sep 2022 13:21:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233346AbiIANU6 (ORCPT ); Thu, 1 Sep 2022 09:20:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233285AbiIANT4 (ORCPT ); Thu, 1 Sep 2022 09:19:56 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 54E4CA457; Thu, 1 Sep 2022 06:19:07 -0700 (PDT) Received: from canpemm500005.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4MJM3c4bkfzkWK6; Thu, 1 Sep 2022 21:15:24 +0800 (CST) Received: from [10.174.178.134] (10.174.178.134) by canpemm500005.china.huawei.com (7.192.104.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 1 Sep 2022 21:19:05 +0800 Subject: Re: [PATCH -next] ext4: ensure data forced to disk when rename To: Jan Kara , Ye Bin CC: , , , References: <20220901062657.1192732-1-yebin10@huawei.com> <20220901083706.mjewb45dufzxcfdk@quack3> From: Zhang Yi Message-ID: Date: Thu, 1 Sep 2022 21:19:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20220901083706.mjewb45dufzxcfdk@quack3> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.178.134] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To canpemm500005.china.huawei.com (7.192.104.229) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/9/1 16:37, Jan Kara wrote: > On Thu 01-09-22 14:26:57, Ye Bin wrote: >> There is issue that data lost when rename new file. Reason is dioread_nolock is >> enabled default now, which map blocks will mark extent unwritten. But inode >> size is changed after submit io. Then read file will return zero if extent is >> unwritten. >> To solve above isuue, wait all data force to disk before rename when enable >> dioread_nolock and enable delay allocate. >> >> Signed-off-by: Ye Bin > > Well, but it was always like that. We do not guarantee that the data is > securely on disk before rename - userspace is responsible for that if it > needs this guarantee. We just want to make the time window shorter and so > start data writeback because lot of userspace is careless. But waiting for > data writeback before rename will significantly slow down some workloads > and IMHO without a good reason. > Hi, Jan Our case is modifing a no-empty file names "data.conf" through vim, it will cp "data.conf" to ".data.conf.swp" firstly, overwrite rename ".data.conf.swp" back to "data.conf" and fsync after modifying. If we power down between rename and fsync, we may lose all data in the original "data.conf" and get a whole zero file. Before we enable dioread_nolock by defalut, the newly appending data may lost, but at least we will not lose the original data in the default data=ordered and auto_da_alloc mode. It seems that dioread_nolock breaks the guarantee provide by auto_da_alloc. Maybe we should add a fsync before rename in vim ? Thanks, Yi.