Re: [PATCH] metadump: handle corruption errors without aborting

Sean Caron
2022-02-07T21:42:43Z

Hi Dave,

Your suggestion was right on. I ran xfs_metadump with the "-a"
parameter and it was able to finish without any more showstoppers.

Thanks!

Sean

On Sun, Feb 6, 2022 at 5:34 PM Dave Chinner <david@fromorbit.com> wrote:
>
> On Wed, Feb 02, 2022 at 06:45:34PM -0500, Sean Caron wrote:
> > Sure! Please see gdb backtrace output below.
> >
> > (gdb) bt
> > #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> > #1 0x00007f289d5c7921 in __GI_abort () at abort.c:79
> > #2 0x00007f289d610967 in __libc_message (action=action@entry=do_abort,
> > fmt=fmt@entry=0x7f289d73db0d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
> > #3 0x00007f289d6179da in malloc_printerr (
> > str=str@entry=0x7f289d73f368 "malloc_consolidate(): invalid chunk
> > size") at malloc.c:5342
> > #4 0x00007f289d617c7e in malloc_consolidate
> > (av=av@entry=0x7f289d972c40 <main_arena>)
> > at malloc.c:4471
> > #5 0x00007f289d61b968 in _int_malloc (av=av@entry=0x7f289d972c40 <main_arena>,
> > bytes=bytes@entry=33328) at malloc.c:3713
> > #6 0x00007f289d620275 in _int_memalign (bytes=32768, alignment=512,
> > av=0x7f289d972c40 <main_arena>)
> > at malloc.c:4683
>
> Ok, so there's nothing wrong with the memalign() parameters being
> passed to glibc, so something has previously caused heap corruption
> that is only now being tripped over trying to allocate memory for a
> new inode cluster buffer.
>
> I wonder if it was the zeroing of the "unused" part of the inode
> data fork area that did this (perhaps a corrupt inode fork offset?)
> so maybe it is worth turning off the stale data zeroing function
> (-a to copy all metadata blocks) so that it doesn't try to interpret
> corrupt metadata to determine what is unused areas or not...
>
> If that does get past this inode, then we'll need to make the
> stale region zeroing a lot more careful and avoid zeroing in the
> case of badly broken metadata.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com