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
