[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/54504: -9/-current WAPBL panic: current transaction too big to flush
The following reply was made to PR kern/54504; it has been noted by GNATS.
From: Jason Thorpe <thorpej%me.com@localhost>
To: NetBSD Kernel Technical Discussion List <tech-kern%netbsd.org@localhost>
Subject: Re: kern/54504: -9/-current WAPBL panic: current transaction too big
Date: Thu, 29 Aug 2019 08:38:00 -0700
> On Aug 29, 2019, at 2:00 AM, kardel%netbsd.org@localhost wrote:
> Workround (presumably): don't use WAPBL.
> Fix: Change WAPBL logic to allow truncation/deletion of big =
files aka avoid running into transaction size limitations.
WAPBL is going to need some help with this -- but in all likelihood, the =
WAPBL-using file system is going to have to participate, as well; i.e. =
it's not just changes to WAPBL in order to solve this problem.
The way some other file systems that I'm familiar with deal with this =
situation is to move the file (or the file's extents / blocks) into a =
"purgatory" (essentially, a hidden directory within the file system) -- =
from the perspective of the original file, the operation is complete and =
the file system consistent. Then, a background task iterates on items =
in the purgatory, operating in chunks that will fit within the =
transaction size limitations.
This sometimes means that space isn't freed immediately, but it works =
pretty well in principle, and you can always add an escape valve that =
boosts the priority of the purgatory task and blocks while it does its =
work if you are desperate for space.
Main Index |
Thread Index |