Hi, Weird story time! I recently moved from 5.15 to 5.18 and noticed that noflushd - a daemon that suspends rotational drives after a while - would now cause dirty writeback buffers to accumulate endlessly for all unstopped devices (like SSDs). Manually calling sync or exceeding the dirty threshold would still work as expected and flush dirty data, just not the periodic writeback. This surprised me since it has been working perfectly fine for the last 12 years or so, incl. 5.15. After some source spelunking I found that noflushd (basically) disables writeback and manually performs periodic fsync on fds of the *un*stopped devices and partitions - as in fsync(<fd of /dev/sda1>). This surprised me, since I never would have expected this to work in the first place, yet it did all these ears. Maybe by accident, maybe intentionally. Since 5.16 the block layer had many cleanups, starting around ~October 2021. Instead of trying to figure out which commit broke the daemon's back, for now I'm more curious about whether this *should* have worked all those years? Is it a bug that it no longer does, or just an accidental behaviour change? Obviously if anybody (Jens, Christoph..?) has an idea what changed this behaviour and thinks it's a bug I'm more than happy to test a fix, however for now I'd be happy to understand what's going on. Oh, and no, I cannot (fully) use hdparm-induced suspend since my HD's firmware is buggy and suspend timer values >11 don't work right. grmbl. Thanks! Holger