>>> On 15.05.17 at 18:52, <sandeen@xxxxxxxxxxx> wrote: > On 5/15/17 4:22 AM, Jan Beulich wrote: >> It seems to have improved the situation (on the first system I had >> the issue on), but leaves me with at least "Operation not permitted" >> upon init scripts (or me manually) rm-ing (or mv-ing) /var/run/*.pid >> (or mv-ing even /var/run itself). I'm not sure how worried I need to >> be, but this surely doesn't look overly healthy yet. The kernel >> warnings are all gone, though. > > xfs_repair simply makes the filesystem consistent, it doesn't perform > any other magic. :) The corruption we saw was related to incorrect > flags set on an inode - in some cases flags like immutable which can > affect access to the file. > > I'm not sure we've made much progress on the root cause of whatever set > those extra flags*, Indeed, and that's the primary aspect that worries me, since with working on the hypervisor or kernel it is going to be unavoidable for a crash to happen now and then. While I realize chances are low to find out any useful information for the two past cases of corruption, do you have any advice on how to collect / preserve necessary information on a sooner or later to be expected next instance? Isn't the most likely explanation that the log replay upon next mount has gone wrong (or the data in the log itself was bogus)? > but all repair will do is make them sane from a > filesystem consistency POV, not from an OS operation POV. Understood. > Check the files in question with lsattr, and see if there are unexpected > flags still set. Indeed I had done this (and the resulting cleanup) before replying. And yes, some of the initial issues went away with clearing stray i or a flags. Yet I wasn't able to tie the /var/run problem to any flag settings. I hope to find time to debug where exactly these errors are being generated, ideally allowing me to understand how to correct their cause. 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
