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

["Konrad Schroder via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/54504; it has been noted by GNATS.

From: Konrad Schroder <perseant%hhhh.org@localhost>
To: Jaromir Dolecek <jaromir.dolecek%gmail.com@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kardel%netbsd.org@localhost
Subject: Re: kern/54504: -9/-current WAPBL panic: current transaction too big,
 to flush
Date: Sat, 26 Jul 2025 12:00:39 -0700

 The problem still exists.  A replicator, in the form of a small(!) 
 filesystem that will crash if it is mounted with "-o log" on an 
 unpatched system, and the file it contains is removed:
 
  Â Â Â  http://www.hhhh.org/perseant/54504/54504.img.xz
 
 Here is another version of the patch.  The problem fixed by this version 
 is that cylinder group bitmap block writes are not accounted for by 
 WAPBL before the decision to flush is made; they are added only when the 
 transaction is flushed.  On a very fragmented filesystem this can cause 
 a transaction overflow if a sufficiently large file is truncated, or 
 even created, since the number of CG bitmap blocks might be equal to the 
 number of blocks already present in the transaction.  This patch solves 
 this issue by having FFS account for the dirty CG blocks and inform 
 WAPBL how much space they will take up.  In addition it performs the 
 same kind of periodic check as my original patch, but with much higher 
 threshold since we can now know the true size of the transaction.
 
 The patch is available at
 
  Â Â Â  http://www.hhhh.org/perseant/54504/ffs-wapbl-check-v4i.diff
 
 I haven't yet looked at performance, but it does seem to fix the issue.
 
 (As an aside, for testing, it's good to have a way to force a filesystem 
 to be fragmented.  For that, I used the following patch, which searches 
 a different cylinder group for each new block allocation:
 
  Â Â Â  http://www.hhhh.org/perseant/54504/ffs-cg-pessimizer.diff
 
 )
 
 Any thoughts?
 
 Thanks,
 
 -Konrad
 
 On 8/28/2020 9:12 PM, Konrad Schroder wrote:
 > > Let me chceck the detail first. It seemms to me the check is inherently not MP safe, and thus not a hood final solution.  I would prefer if it properly bailed out if unallocation registration fails, as is done elsewhere, rather then checking size before operation.
 > >
 > > Please dont commit this for now.  I should be again available later in the week, I am currentlt on move so cant check.
 > >
 > > Jaromir
 >
 > Okay, I won't commit until you give me the green light.  I've added the same mutex lock as is present in wapbl_begin(), and the result is at
 >
 > 	http://www.hhhh.org/perseant/ffs-wapbl-check-r3.diff
 >
 > It would of course be possible to try to allocate space for all of the blocks, but managing the allocations for the other metadata (cylinder groups, in particular) sounds more difficult than it's worth.  If I understand correctly, to be conservative you'd need to allocate one CG bitmap block per data block freed, plus indirect blocks.  That's why I went for the much simpler, though admittedly crude, method of checking every once in a while (after every indirect block freed), while being very conservative about how much space is needed.
 >
 > Thanks,
 >
 > -Konrad