On 7/3/20 12:30 PM, David Sterba wrote:
On Tue, Jun 30, 2020 at 09:58:58AM -0400, Josef Bacik wrote:
We've had two different things in place to reserve data and metadata space,
because generally speaking data is much simpler. However the data reservations
still suffered from the same issues that plagued metadata reservations, you
could get multiple tasks racing in to get reservations. This causes problems
with cases like write/delete loops where we should be able to fill up the fs,
delete everything, and go again. You would sometimes race with a flusher that's
trying to unpin the free space, take it's reservations, and then it would fail.
Fix this by moving the data reservations under the metadata ticketing
infrastructure. This gets rid of that problem, and simplifies our enospc code
more by consolidating it into a single path. Thanks,
I created a for-next-20200703 snapshot with this branch included, and it
went up to generic/102 and got stuck due to softlockups. This could mean
the machine is overloaded but it usually recovers from that, while not
in this case as it took more than 7 hours before I killed the VM.
There is the dio-iomap so the patchsets could interact in some way, I'll
do more tests next week, this is an early warning that something might
be going on.
Softlockup in __slab_alloc, I think we were just the victim here. Thanks,
Josef
