From: Jan Kara <jack@suse.cz>
To: Chung-Chiang Cheng <shepjeng@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
Chung-Chiang Cheng <cccheng@synology.com>,
linux-ext4@vger.kernel.org, tytso@mit.edu,
adilger.kernel@dilger.ca, yi.zhang@huawei.com,
kernel@cccheng.net, Robbie Ko <robbieko@synology.com>
Subject: Re: [PATCH] ext4: defer updating i_disksize until endio
Date: Mon, 27 Mar 2023 13:34:03 +0200 [thread overview]
Message-ID: <20230327113403.25iafutxorqezugs@quack3> (raw)
In-Reply-To: <CAHuHWt=LaNBwNy-1RY2-OZ4zGKEgTBfZZGWoQJSjL3ADbRRCoQ@mail.gmail.com>
On Mon 27-03-23 18:28:55, Chung-Chiang Cheng wrote:
> On Mon, Mar 27, 2023 at 5:29 PM Jan Kara <jack@suse.cz> wrote:
> >
> > As Zhang Yi already noted in his review, this is expected at least with
> > data=writeback mount option. With data=ordered this should not happen
> > though as the commit of the transaction with i_disksize update will wait
> > for page writeback to complete (this is exactly the reason why data=ordered
> > exists after all). Are you able to observe this problem with data=ordered
> > mount option?
> >
> > Honza
>
> It's a pity that this issue also occurs with data=ordered due to delayed
> allocation being enabled by default. If delayed allocation were disabled,
> it would not be as easy to reproduce.
Ah, ok. With data=ordered and expanding within the last block, you are
right you can see zeros at the end of the file after a crash. We were
discussing this in the past already but decided not to improve this because
the fix would have performance cost we didn't want to impose on users.
> This is because if data is written to the end of a file and the block is
> allocated, the new i_disksize will be immediately committed to the journal
> at ext4_da_write_end(), but the writeback procedure is not yet triggered.
> By default, ext4 commits the journal every 5 seconds, but a dirty page may
> not be written back until 30 seconds later. This is not a short time window,
> and any improper shutdown during this time may lead to the issue :(
Yeah, I agree. The time window is not small. What we could do and what
could even bring some performance benefit is if we moved the i_disksize
update from ext4_da_write_end() to ext4_do_writepages(). Currently we do
the i_disksize update only in mpage_map_and_submit_extent() but we could
add a similar logic when exiting from ext4_do_writepages() to update
i_disksize for written back pages beyond i_disksize which didn't need block
allocation. *Except* there is a problem that we couldn't do this i_disksize
update when the pages are written from jbd2 during ordered data writeback
(we cannot start transaction in that context). And this is nasty because
we will completely loose the i_disksize update. We could handle it by
redirtying the tail page in this case but it gets a bit ugly...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
prev parent reply other threads:[~2023-03-27 11:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-24 9:29 [PATCH] ext4: defer updating i_disksize until endio Chung-Chiang Cheng
2023-03-24 11:57 ` kernel test robot
2023-03-24 12:58 ` Zhang Yi
2023-03-24 12:59 ` kernel test robot
2023-03-27 9:29 ` Jan Kara
2023-03-27 10:28 ` Chung-Chiang Cheng
2023-03-27 11:17 ` Zhang Yi
2023-03-29 3:36 ` Chung-Chiang Cheng
2023-03-29 11:37 ` Zhang Yi
2023-03-27 11:34 ` Jan Kara [this message]
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=20230327113403.25iafutxorqezugs@quack3 \
--to=jack@suse.cz \
--cc=adilger.kernel@dilger.ca \
--cc=cccheng@synology.com \
--cc=kernel@cccheng.net \
--cc=linux-ext4@vger.kernel.org \
--cc=robbieko@synology.com \
--cc=shepjeng@gmail.com \
--cc=tytso@mit.edu \
--cc=yi.zhang@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