Re: data rolled back 5 hours after crash, long fsync running times, watchdog evasion on 5.4.11

[Martin Steigerwald <martin@lichtvoll.de>]

Zygo Blaxell - 09.02.20, 01:43:07 CET:
> Up to that point, a few processes have been blocked for up to 5 hours,
> but this is not unusual on a big filesystem given #1.  Usually
> processes that read the filesystem (e.g. calling lstat) are not
> blocked, unless they try to access a directory being modified by a
> process that is blocked. lstat() being blocked is unusual.

This is really funny, cause what you consider not being unusual, I'd 
consider a bug or at least a huge limitation.

But in a sense I never really got that processed can be stuck in 
uninterruptible sleep on Linux or Unix *at all*. Such a situation 
without giving a user at least the ability to end it by saying "I don't 
care about the data that process is to write, let me remove it already" 
for me is a major limitation to what appears to be kind of specific to 
the UNIX architecture or at least the way the Linux virtual memory 
manager is working.

That written I may be completely ignorant of something very important 
here and some may tell me it can't be any other way for this and that 
reason. Currently I still think it can.

And even if uninterruptible sleep can still happen cause it is really 
necessary, five hours is at least about five hours minus probably a minute 
or so too long.

Ciao,
-- 
Martin