Q: fsync on a blockdev fd worked in 5.15, but no longer does. Should it?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux