Re: Weird xfs_repair error

[Emmanuel Florac <eflorac@intellique.com>]

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

Le Thu, 6 Jul 2017 09:48:05 -0400
Brian Foster <bfoster@redhat.com> écrivait:

> > 
> > I've run xfs_repair 4.9 on the xfs_mdrestored image. It dumps an
> > insane lot of errors (the output log is 65MB)  and ends with this
> > very strange message:
> > 
> > disconnected inode 26417467, moving to lost+found
> > disconnected inode 26417468, moving to lost+found
> > disconnected inode 26417469, moving to lost+found
> > disconnected inode 26417470, moving to lost+found
> > 
> > fatal error -- name create failed in lost+found (117), filesystem
> > may be out of space
> > 
> > Even stranger, after mounting back the image, there is no lost+found
> > anywhere to be found! However the filesystem has lots of free space
> > and free inodes, how come?
> >   
> 
> Did you originally run xfs_repair using the -n option? I'd guess not
> if it ultimately failed making a modification, but if so, something
> to be aware of is that it skips warning about a dirty log and
> potentially can report much more corruption than after a log recovery
> occurs. It might be worth running after an attempted log recovery.

I've mounted the FS first to clean up the log. I've also tried making a
bigger image, in case the hosting file was too small. No dice.
 
> Otherwise, I'd be curious about the state of the fs after the above
> error. Does 'xfs_repair -n' continue to report errors?

You're onto something here. In fact each time I re-run xfs_repair, it
still spits out many errors and ends with the same line as I mentioned
previously.
However each run of xfs_repair generates fewer errors. The first log
was 65MB; the second 7.5, the third 3.8MB. I'll try running it again
and again to see how it ends...

> Also the above suggests that lost+found existed (in a corrupted state)
> prior to the initial repair attempt, yes? If so, it might be
> interesting to identify the inode # of lost+found to follow what
> xfs_repair does to that inode during the initial run (e.g., if
> lost+found is corrupted and is attempted to be used before it is
> fixed up or something of that nature).

OK I'll try to restore the dump again to check "lost+found". Maybe I
could remove it before running the repair, but that's unlikely...

-- 
------------------------------------------------------------------------
Emmanuel Florac     |   Direction technique
                    |   Intellique
                    |	<eflorac@intellique.com>
                    |   +33 1 78 94 84 02
------------------------------------------------------------------------

[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 181 bytes --]