On Thu, May 15, 2014 at 07:54:57AM +1000, Dave Chinner wrote: > On Tue, May 13, 2014 at 08:31:02PM +0200, Mateusz Guzik wrote: > > This helps hang troubleshooting efforts when only dmesg is available. > > I really don't think that spamming dmesg every time a filesystem is > frozen or thawed is a good idea. This happens a *lot* when systems > are using snapshots, and for the most part nobody cares about > freeze/thaw cycles because they almost always work just fine. >
I agree it may get noisy. > I'd think that /proc/self/mounts would be a much better place to > indicate that the fs is frozen. After all, that's where we tell > people whether the filesystem is ro or rw, and frozen is just > a temporary, non-invasive ro state... > Except you can't inspect /proc/self/mounts when the only thing you got is dmesg, so this does not really help my case. That said, I'll try to come up with a different solution. Poorly reported side-effects of frozen I/O are only a part of the real problem which is hung task detector being able to typically report backtraces of "victims" only. I came up with printks becuase these are a cheap way and would help us out in a lot of cases. So general idea is to support providing callbacks when setting tasks to TASK_UNINTERRUPTIBLE which could either tell the user what's up directly or would perform some heuristics. I'll post this in a separate thread later, maybe with PoC. Thanks, -- Mateusz Guzik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
