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
