Re: kern/54504: -9/-current WAPBL panic: current transaction too big to flush

[Jason Thorpe <thorpej%me.com@localhost>]

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>
Cc: netbsd-bugs%netbsd.org@localhost,
 "gnats-bugs%netbsd.org@localhost" <gnats-bugs%NetBSD.org@localhost>
Subject: Re: kern/54504: -9/-current WAPBL panic: current transaction too big
 to flush
Date: Thu, 29 Aug 2019 08:38:00 -0700

 > On Aug 29, 2019, at 2:00 AM, kardel%netbsd.org@localhost wrote:
 >=20
 > 	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.
 
 -- thorpej