linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Wang Jianchao <jianchao.wan9@gmail.com>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ext4: get discard out of jbd2 commit kthread
Date: Tue, 18 May 2021 10:57:44 -0400	[thread overview]
Message-ID: <YKPV6FZWfoUD3bgL@mit.edu> (raw)
In-Reply-To: <c7c00420-ed5c-0f5d-23c1-1c64b1800778@gmail.com>

On Tue, May 18, 2021 at 09:19:13AM +0800, Wang Jianchao wrote:
> > That way we don't need to move all of this to a kworker context.
> 
> The submit_bio also needs to be out of jbd2 commit kthread as it may be
> blocked due to blk-wbt or no enough request tag. ;)

Actually, there's a bigger deal that I hadn't realized, about why we
is why are currently using submit_bio_wait().  We *must* wait until
discard has completed before we call ext4_free_data_in_buddy(), which
is what allows those blocks to be reused by the block allocator.

If the discard happens after we reallocate the block, there is a good
chance that we will end up corrupting a data or metadata block,
leading to user data loss.

There's another corollary to this; if you use blk-wbt, and you are
doing lots of deletes, and we move this all to a writeback thread,
this *significantly* increases the chance that the user will see
ENOSPC errors in the case where they are with a very full (close to
100% used) file system.

I'd argue that this is a *really* good reason why using mount -o
discard is Just A Bad Idea if you are running with blk-wbt.  If
discards are slow, using fstrim is a much better choice.  It's also
the case that for most SSD's and workloads, doing frequent discards
doesn't actually help that much.  The write endurance of the device is
not compromised that much if you only run fs-trim and discard unused
blocks once a day, or even once a week --- I only recommend use of
mount -o discard in cases where the discard operation is effectively
free.  (e.g., in cases where the FTL is implemented on the Host OS, or
you are running with super-fast flash which is PCIe or NVMe attached.)

Cheers,

					- Ted

  reply	other threads:[~2021-05-18 14:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17  3:57 [PATCH] ext4: get discard out of jbd2 commit kthread Wang Jianchao
2021-05-17 20:52 ` Theodore Y. Ts'o
2021-05-18  1:19   ` Wang Jianchao
2021-05-18 14:57     ` Theodore Y. Ts'o [this message]
2021-05-19  1:27       ` Wang Jianchao
2021-05-19 15:08         ` Theodore Y. Ts'o
2021-05-20  1:20           ` Wang Jianchao

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=YKPV6FZWfoUD3bgL@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=jianchao.wan9@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).