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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
