Re: xfs_repair: phase6.c:1129: mv_orphanage: Assertion `err == 2' failed.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Sep 22, 2019 at 9:25 PM Arkadiusz Miśkiewicz
<a.miskiewicz@xxxxxxxxx> wrote:
>
> On 16/09/2019 23:35, Eric Sandeen wrote:
> > On 9/15/19 7:44 AM, Arkadiusz Miśkiewicz wrote:
> >>
> >> Hello.
> >>
> >> xfsprogs 5.2.1 and:
> >>
> >> disconnected dir inode 9185193405, moving to lost+found
> >> disconnected dir inode 9185193417, moving to lost+found
> >> disconnected dir inode 9185194001, moving to lost+found
> >> disconnected dir inode 9185194004, moving to lost+found
> >> disconnected dir inode 9185194010, moving to lost+found
> >> disconnected dir inode 9185194012, moving to lost+found
> >> disconnected dir inode 9185194018, moving to lost+found
> >> disconnected dir inode 9185194027, moving to lost+found
> >> disconnected dir inode 9185205370, moving to lost+found
> >> disconnected dir inode 9185209007, moving to lost+found
> >> corrupt dinode 9185209007, (btree extents).
> >> Metadata corruption detected at 0x449621, inode 0x2237b2aaf
> >> libxfs_iread_extents
> >> xfs_repair: phase6.c:1129: mv_orphanage: Assertion `err == 2' failed.
> >> Aborted
> >
> >>
> >>
> >> # grep -A1 -B1 9185209007 log
> >> entry ".." at block 0 offset 80 in directory inode 9185141346 references
> >> non-existent inode 6454491396
> >> entry ".." at block 0 offset 80 in directory inode 9185209007 references
> >> free inode 62881485764
> >> entry ".." at block 0 offset 80 in directory inode 9185220220 references
> >> free inode 6454492606
> >> --
> >> rebuilding directory inode 9185141346
> >> entry ".." in directory inode 9185209007 points to free inode
> >> 62881485764, marking entry to be junked
> >> rebuilding directory inode 9185209007
> >> name create failed in ino 9185209007 (117), filesystem may be out of space
> >
> > 117 is EUCLEAN/EFSCORRUPTED even though we were in the process of rebuilding it. :(
> >
> > so this is probably why a subsequent attempt to move it to lost+found failed as well?
> >
> > Is this a metadumpable filesystem...?
>
>
> It's one of my big fses but metadump can't deal with it:
>
> > [...]
> > Copied 103433024 of 165039360 inodes (24 of 39 AGs)        Unknown directory buffer type!
> > Copied 104001280 of 165039360 inodes (24 of 39 AGs)        Unknown directory buffer type!
> > Copied 105465088 of 165039360 inodes (24 of 39 AGs)        Unknown directory buffer type!
> > Copied 107092608 of 165039360 inodes (25 of 39 AGs)        Metadata corruption detected at 0x473455, xfs_dir3_leaf1 block 0xc8471ce78/0x1000
> > Segmentation fault (core dumped)

You could still try to dump without data zeroing (metadump -a), if
this is acceptable to you.




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux