From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-ext4@vger.kernel.org, linux-fscrypt@vger.kernel.org
Subject: Re: [PATCH] ext4: re-enable extent zeroout optimization on encrypted files
Date: Mon, 13 Jan 2020 14:35:08 -0500 [thread overview]
Message-ID: <20200113193508.GD76141@mit.edu> (raw)
In-Reply-To: <20191226161114.53606-1-ebiggers@kernel.org>
On Thu, Dec 26, 2019 at 10:11:14AM -0600, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> For encrypted files, commit 36086d43f657 ("ext4 crypto: fix bugs in
> ext4_encrypted_zeroout()") disabled the optimization where when a write
> occurs to the middle of an unwritten extent, the head and/or tail of the
> extent (when they aren't too large) are zeroed out, turned into an
> initialized extent, and merged with the part being written to. This
> optimization helps prevent fragmentation of the extent tree.
>
> However, disabling this optimization also made fscrypt_zeroout_range()
> nearly impossible to test, as now it's only reachable via the very rare
> case in ext4_split_extent_at() where allocating a new extent tree block
> fails due to ENOSPC. 'gce-xfstests -c ext4/encrypt -g auto' doesn't
> even hit this at all.
>
> It's preferable to avoid really rare cases that are hard to test.
>
> That commit also cited data corruption in xfstest generic/127 as a
> reason to disable the extent zeroout optimization, but that's no longer
> reproducible anymore. It also cited fscrypt_zeroout_range() having poor
> performance, but I've written a patch to fix that.
>
> Therefore, re-enable the extent zeroout optimization on encrypted files.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Thanks, applied.
- Ted
prev parent reply other threads:[~2020-01-13 19:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-26 16:11 [PATCH] ext4: re-enable extent zeroout optimization on encrypted files Eric Biggers
2020-01-13 19:35 ` Theodore Y. Ts'o [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=20200113193508.GD76141@mit.edu \
--to=tytso@mit.edu \
--cc=ebiggers@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fscrypt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.