On Thu, May 12, 2022 at 09:56:46AM -0400, Theodore Ts'o wrote:
On Thu, May 12, 2022 at 08:18:24PM +0900, Byungchul Park wrote:
I have a question about this one. Yes, it would never been stuck thanks to timeout. However, IIUC, timeouts are not supposed to expire in normal cases. So I thought a timeout expiration means not a normal case so need to inform it in terms of dependency so as to prevent further expiraton. That's why I have been trying to track even timeout'ed APIs.
As I beleive I've already pointed out to you previously in ext4 and ocfs2, the jbd2 timeout every five seconds happens **all** the time while the file system is mounted. Commits more frequently than five seconds is the exception case, at least for desktops/laptop workloads.
Thanks, Ted. It's easy to stop tracking APIs with timeout. I've been just afraid that the cases that we want to suppress anyway will be skipped.
However, I should stop it if it produces too many false alarms.
We *don't* get to the timeout only when a userspace process calls fsync(2), or if the journal was incorrectly sized by the system administrator so that it's too small, and the workload has so many file system mutations that we have to prematurely close the transaction ahead of the 5 second timeout.
Yeah... It's how journaling works. Thanks.
Do you think DEPT shouldn't track timeout APIs? If I was wrong, I shouldn't track the timeout APIs any more.
DEPT tracking timeouts will cause false positives in at least some cases. At the very least, there needs to be an easy way to suppress these false positives on a per wait/mutex/spinlock basis.
The easy way is to stop tracking those that are along with timeout until DEPT starts to consider waits/events by timeout functionality itself.
Thanks.
Byungchul
- Ted