On Wed, Jan 29, 2020 at 03:55:06PM -0700, Chris Murphy wrote: > On Wed, Jan 29, 2020 at 2:20 PM Martin Steigerwald <martin@xxxxxxxxxxxx> wrote: > > > > So if its just a cosmetic issue then I can wait for the patch to land in > > linux-stable. Or does it still need testing? > > I'm not seeing it in linux-next. A reasonable short term work around > is mount option 'metadata_ratio=1' and that's what needs more testing, > because it seems decently likely mortal users will need an easy work > around until a fix gets backported to stable. And that's gonna be a > while, me thinks. We're looking into some fix that could be backported, as it affects a long-term kernel (5.4). The fix https://lore.kernel.org/linux-btrfs/20200115034128.32889-1-wqu@xxxxxxxx/ IMHO works by accident and is not good even as a workaround, only papers over the problem in some cases. The size of metadata over-reservation (caused by a change in the logic that estimates the 'over-' part) adds up to the global block reserve (that's permanent and as last resort reserve for deletion). In other words "we're making this larger by number A, so let's subtract some number B". The fix is to use A. > Is that mount option sufficient? Or does it take a filtered balance? > What's the most minimal balance needed? I'm hoping -dlimit=1 > > I can't figure out a way to trigger this though, otherwise I'd be > doing more testing. I haven't checked but I think the suggested workarounds affect statfs as a side effect. Also as the reservations are temporary, the numbers change again after a sync.
