Re: [PATCH 2/5] mkfs: don't let internal logs consume more than 95% of an AG

[Eric Sandeen <sandeen@sandeen.net>]

On 3/16/22 8:50 AM, Eric Sandeen wrote:
> On 3/15/22 6:23 PM, Darrick J. Wong wrote:
>> From: Darrick J. Wong <djwong@kernel.org>
>>
>> Currently, we don't let an internal log consume every last block in an
>> AG.  According to the comment, we're doing this to avoid tripping AGF
>> verifiers if freeblks==0, but on a modern filesystem this isn't
>> sufficient to avoid problems.  First, the per-AG reservations for
>> reflink and rmap claim up to about 1.7% of each AG for btree expansion,
> 
> Hm, will that be a factor if the log consumes every last block in that
> AG? Or is the problem that if we consume "most" blocks, that leaves the
> possibility of reflink/rmap btree expansion subsequently failing because
> we do have a little room for new allocations in that AG?
> 
> Or is it a problem right out of the gate because the per-ag reservations
> collide with a maximal log before the filesystem is even in use?

Darrick, any comment on this? What did you actually run into that prompted
this change?

Still bugs me a little that a manually-sized log escapes this limit, and if
it's needed for proper functioning, we should probably enforce it everywhere.

I do understand that the existing code only validates auto-sized logs. But
I don't want to sweep this under the rug, even if we choose to not fix it all
right now.

Mostly looking for clarification on the what fails and how, with the current
code.

Thanks,
-Eric