Le Mon, 24 Jul 2017 10:51:25 -0400 Brian Foster <bfoster@xxxxxxxxxx> écrivait: > There are several fixes in-flight for the issues uncovered by this > metadump. I think you'll want to include the following 3 patches to > xfsprogs: > > http://marc.info/?l=linux-xfs&m=150047977108174&w=2 > http://marc.info/?l=linux-xfs&m=150040481220074&w=2 > http://marc.info/?l=linux-xfs&m=150040481820076&w=2 > > Note that the last 2 patches are probably going to be reworked into a > different implementation. The idea here is ultimately to avoid running > the verifier in a case where it disrupts xfs_repair, so using this > intermediate patch series should be good enough to build a custom > binary that allows xfs_repair to eventually piece the fs back > together. You could alternatively just hack xfs_dir2_sf_verify() to > return 0. > > Note that I would highly recommend to test whatever you build against > your metadump before the original fs. > You bet... I would even try salvaging files from the unrepaired fs if possible, but it's probably not workable. For info I tried the new 4.12, and it fails reliably like this (after gazillions of metadata errors, etc): bad hash table for directory inode 4295385906 (no data entry): rebuilding rebuilding directory inode 4295385906 7f42b14f8780: Badness in key lookup (length) bp=(bno 0x0, len 4096 bytes) key=(bno 0x0, len 512 bytes) 7f42b14f8780: Badness in key lookup (length) bp=(bno 0x0, len 4096 bytes) key=(bno 0x0, len 512 bytes) Invalid inode number 0x0 xfs_dir_ino_validate: XFS_ERROR_REPORT fatal error -- couldn't map inode 4295400241, err = 117 At least it's always the same error (previous versions were ending with various logs sizes and errors). -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <eflorac@xxxxxxxxxxxxxx> | +33 1 78 94 84 02 ------------------------------------------------------------------------
Attachment:
pgpZ1I5zZR3EM.pgp
Description: Signature digitale OpenPGP
