On 2012年10月15日 15:36, Dave Chinner wrote:
On Mon, Oct 15, 2012 at 12:24:59PM +0900, Fernando Luis Vazquez Cao wrote:
On 2012/10/13 10:06, Dave Chinner wrote:
On Fri, Oct 12, 2012 at 06:47:32PM +0900, Fernando Luis Vázquez Cao wrote:
Any process attempting to write to a frozen filesystem uninterruptibly and
unkillably waits for the filesystem to be thawed. This wait is of unbounded
length. Ignore such waits in the hung_task detector.
Filesystems should not be frozen for long enough to trigger the hung
task detector under normal usage. IMO, if you are freezing a
filesystem for that long, then you're either doing something wrong
or something has gone wrong, and in either case I think we should be
emitting warnings...
The problem is that in production systems situations where
a filesystem remains brozen for long periods are not uncommon.
A typical example is as follows: the control daemon or script that
controls the freeze/thaw using the fsfreeze ioctls dies, the next
There's your problem. Fix that, don't turn off useful warnings that
indicate something has gone wrong.
It is not my problem. It is the enterprise distro's user's problem.
As I mentioned in my previous email if you want to emit a
warning do it in the right place and make sure that it is
something informative. hung_check certainly isn't the
right place to do it.
A failure in a user space script should not lead to a kernel
panic or to a flood of process stack dumps in the system log
administrators cannot interpret (a common complaint from
our customers). This is the behaviour this patch is trying to
fix.
Thanks,
Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
