]> git.baikalelectronics.ru Git - kernel.git/commit
Revert "ext4: make __ext4_get_inode_loc plug"
authorLinus Torvalds <torvalds@linux-foundation.org>
Sun, 15 Sep 2019 19:32:03 +0000 (12:32 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Sun, 15 Sep 2019 19:32:03 +0000 (12:32 -0700)
commitf7b8746e6b5bd70fb337ac1bf87ff6b633a3ea2f
tree48a69287e39099681405f1981e8280cf2d780835
parentf3143b62e24f402dab508906cde94d7a16132d74
Revert "ext4: make __ext4_get_inode_loc plug"

This reverts commit caa902c15af96352042ad2d31f7b6eb48854cf98.

This is sad, and done for all the wrong reasons.  Because that commit is
good, and does exactly what it says: avoids a lot of small disk requests
for the inode table read-ahead.

However, it turns out that it causes an entirely unrelated problem: the
getrandom() system call was introduced back in 2014 by commit
06acaadeaeb8 ("random: introduce getrandom(2) system call"), and people
use it as a convenient source of good random numbers.

But part of the current semantics for getrandom() is that it waits for
the entropy pool to fill at least partially (unlike /dev/urandom).  And
at least ArchLinux apparently has a systemd that uses getrandom() at
boot time, and the improvements in IO patterns means that existing
installations suddenly start hanging, waiting for entropy that will
never happen.

It seems to be an unlucky combination of not _quite_ enough entropy,
together with a particular systemd version and configuration.  Lennart
says that the systemd-random-seed process (which is what does this early
access) is supposed to not block any other boot activity, but sadly that
doesn't actually seem to be the case (possibly due bogus dependencies on
cryptsetup for encrypted swapspace).

The correct fix is to fix getrandom() to not block when it's not
appropriate, but that fix is going to take a lot more discussion.  Do we
just make it act like /dev/urandom by default, and add a new flag for
"wait for entropy"? Do we add a boot-time option? Or do we just limit
the amount of time it will wait for entropy?

So in the meantime, we do the revert to give us time to discuss the
eventual fix for the fundamental problem, at which point we can re-apply
the ext4 inode table access optimization.

Reported-by: Ahmed S. Darwish <darwish.07@gmail.com>
Cc: Ted Ts'o <tytso@mit.edu>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Alexander E. Patrakov <patrakov@gmail.com>
Cc: Lennart Poettering <mzxreary@0pointer.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs/ext4/inode.c