>>> 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. >> Iirc the inode numbers didn't change, >> but in some cases the associated files did (namely when these >> weren't ones created very soon after mount, i.e. when the >> order of things is less predictable - it was in particular /var/run/ >> which was affected there). That's the reason I've refrained >> from trying to xfs_repair the issues in this second instance. >> >> Now one question obviously is whether the repair strategy >> changed between the xfs_repair versions I use (3.1.8 on the > > That's extremely old - Mar 2012, FWIW. > >> system that I sent you the meta data dump from, likely the >> same on the other one): Mine clears the inodes with the bad >> RT flag, while - namely considering the subsequent "block ... >> type unknown" reported by xfs_check - it might instead be >> possible to reconstruct the files and clear the RT flag. But of >> course I know nothing about XFS internals... > > That is what xfs_repair did here - it cleared the bad flags and left > the rest intact. For all of the cases? According to my run, "Bad flags set in inode..." would lead to the flags being corrected, but "found inode ... claiming to be a real-time file" would lead to the inode being cleared. But of course I can imagine this being dealt with differently in newer versions of the tool... >>> *Each of the 3 problematic inodes has an odd assortment of flags >>> set (think chattr type flags) - some have immutable, some have >>> noatime, some have nodump, etc. These are what cause xfs_repair >>> t ocomplain. It seems unlikely that any of these were actually set >>> on your filesystem, as these are the only ones with any flags set. >>> After repair, they're showing: >>> >>> --S---dA----------- mnt/log/messages >>> --S-i--A----------- mnt/lib/sudo/jbeulich/0 >>> --S----A----------- mnt/lib/xenstored/tdb >>> >>> Did you happen to set chattr flags on these files intentionally? >> >> I certainly didn't. As I don't know how to produce this form of >> flags display, I can't (for now) compare with what a healthy >> system has there. > > The above is from the lsattr display. (I suppose it's plausible that > i.e. messages would have "append-only" set by something ...) On a healthy system all three of them have no flags set at all. Jan -- 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
