ext4: re-enable extent zeroout optimization on encrypted files
authorEric Biggers <ebiggers@google.com>
Thu, 26 Dec 2019 16:11:14 +0000 (10:11 -0600)
committerTheodore Ts'o <tytso@mit.edu>
Fri, 17 Jan 2020 21:24:53 +0000 (16:24 -0500)
commitd85926474ffd5395dc39dbbedb969c31c4059a61
treeb493e85ca8ce39a4a4eebdea3b67829c9723f018
parent33b4cc2501d323feef3cc3ec9a084d80bef5b5e8
ext4: re-enable extent zeroout optimization on encrypted files

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>
Link: https://lore.kernel.org/r/20191226161114.53606-1-ebiggers@kernel.org
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
fs/ext4/extents.c