On Fri, Jul 04, 2014 at 03:29:31AM +0200, Carlos E. R. wrote:
> On Friday, 2014-07-04 at 10:04 +1000, Dave Chinner wrote:
> >On Fri, Jul 04, 2014 at 01:34:52AM +0200, Carlos E. R. wrote:
> >>Ok, true, there is no formal "Oops".
> >>But no, the system does not remains fine, I had to hit the hardware
> >>reset or power off button to get out.
> >That usually only happens when the root filesystem is shut down and
> >you can't access any of the binaries needed to run the system. Is
> >the filesystem that is shutting down the root?
> No, it is not. Root is separate and using ext4. The problematic one
> is /home.
> What I did, as far I remember, was, when I noticed that home had
> failed and was read only, to switch to runlevel 1, umount /home
> (killing the apps that were still using it), then tried to mount it
> again to replay the log, prior to using xfs-repair on it. Mount
> hung. ctrl-alt-supr failed, or appeared to fail. So reset button...
That's a completely different issue to having a shutdown filesystem
hang your system. That's a mount problem, and likely a known issue.
You need to be specific when describing a problem, otherwise we
waste time going down the wrong paths.
> >>No, the on disk filesystem is not healthy. If I continue using it,
> >>after reboot and using "xfs_repair" several times, it fails again
> >>within a day.
> >After at least one hibernation and thaw cycle, right?
> Yes. 3, I think.
Then hibernation has caused the corruption. It may take some time
for the corruption to be detected, but there isn't any doubt in my
mind that hibernation is the cause of your problems.
So, until we have kernel fixes, you'd do best to turn off
hibernation. If you can't live with leaving your machine powered up
or switching it off, then use suspend-to-ram rather than
suspend-to-disk to avoid the problematic snapshot/restore