On 5/12/17 9:09 AM, Jan Beulich wrote: >>>> On 12.05.17 at 15:56, <sandeen@xxxxxxxxxxx> wrote: >> On 5/12/17 1:26 AM, Jan Beulich wrote: >>> So on the earlier instance, where I did run actual repairs (and >>> indeed multiple of them), the problem re-surfaces every time >>> I mount the volume again. >> Ok, what is the exact sequence there, from repair to re-corruption? > Simply mount the volume after repairing (with or without an > intermediate reboot) and access respective pieces of the fs > again. As said, with /var/run affected on that first occasion, > I couldn't even cleanly boot again without seeing the > corruption re-surface. Mount under what kernel, and access in what way? I'm looking for a recipe to reproduce what you've seen using the metadump you've provided. However: With further testing I see that xfs_repair v3.1.8 /does not/ entirely fix the fs; if I run 3.1.8 and then run upstream repair, it finds and fixes more bad flags on inode 764 (lib/xenstored/tdb) that 3.1.8 didn't touch. The verifiers in an upstream kernel may keep tripping over that until newer repair fixes it... Thanks, -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
