Re: xfs: Assertion failed in xfs_ag_resv_init()

[Andre Noll <maan@tuebingen.mpg.de>]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

On Tue, Apr 30, 12:18, Darrick J. Wong wrote
> > commit f847bda4d612744ff1812788417bd8df41a806d3
> > Author: Dave Chinner <dchinner@redhat.com>
> > Date:   Mon Nov 19 13:31:08 2018 -0800
> > 
> >     xfs: finobt AG reserves don't consider last AG can be a runt
> >     
> >     This is a backport of upstream commit c08768977b9 and the part of
> >     21ec54168b36 which is needed by c08768977b9.
> 
> You could send this patch to the stable list, but my guess is that
> they'd prefer a straight backport of all three commits...

Hm, cherry-picking the first commit onto 4.9,171 already gives
four conflicting files. The conflicts are trivial to resolve (git
cherry-pick -xX theirs 21ec54168b36 does it), but that doesn't
compile because xfs_btree_query_all() is missing.  So e9a2599a249ed
(xfs: create a function to query all records in a btree) is needed as
well. But then, applying 86210fbebae (xfs: move various type verifiers
to common file) on top of that gives non-trivial conflicts.

So, for automatic backporting we would need to cherry-pick even more,
and each backported commit should be tested of course. Given this, do
you still think Greg prefers a rather large set of straight backports
over the simple commit that just pulls in the missing function?

I guess the important question is how much impact this issue
has on production systems (i.e., on CONFIG_XFS_DEBUG=n kernels,
where the assert statement is not compiled in). If the unpatched
xfs_inobt_max_size() is very unlikely to cause problems on such
systems, we might as well live with it.

Thanks
Andre
-- 
Max Planck Institute for Developmental Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]