linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zhang Yi <yi.zhang@huawei.com>
To: Jan Kara <jack@suse.cz>, Ye Bin <yebin10@huawei.com>
Cc: <tytso@mit.edu>, <adilger.kernel@dilger.ca>,
	<linux-ext4@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next] ext4: ensure data forced to disk when rename
Date: Thu, 1 Sep 2022 21:19:04 +0800	[thread overview]
Message-ID: <ce8666e2-c224-79f9-7770-f87b31d122e3@huawei.com> (raw)
In-Reply-To: <20220901083706.mjewb45dufzxcfdk@quack3>

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 <yebin10@huawei.com>
> 
> 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.

  reply	other threads:[~2022-09-01 13:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01  6:26 [PATCH -next] ext4: ensure data forced to disk when rename Ye Bin
2022-09-01  8:37 ` Jan Kara
2022-09-01 13:19   ` Zhang Yi [this message]
2022-09-01 14:45     ` Theodore Ts'o
2022-09-02  3:31       ` Zhang Yi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ce8666e2-c224-79f9-7770-f87b31d122e3@huawei.com \
    --to=yi.zhang@huawei.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=yebin10@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).