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

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

[Holger Hoffstätte]

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

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

[Christoph Hellwig]

On Wed, Jun 01, 2022 at 10:19:40PM +0200, Holger Hoffstätte wrote:
> 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.

I just tested fsync on SCSI disk and NVMe SSDs and they make it down
perfectly fine to the driver and device as Synchronize Cache / Flush
commands, including the block device node for a partition.

Everything else would be really horrible for data integrity anyway..

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

[Holger Hoffstätte]

On 2022-06-02 07:59, Christoph Hellwig wrote:
> On Wed, Jun 01, 2022 at 10:19:40PM +0200, Holger Hoffstätte wrote:
>> 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.
> 
> I just tested fsync on SCSI disk and NVMe SSDs and they make it down
> perfectly fine to the driver and device as Synchronize Cache / Flush
> commands, including the block device node for a partition.
> 
> Everything else would be really horrible for data integrity anyway..

Thanks for confirming. Unfortunately that still doesn't explain
why dirty buffers now keep accumulating, but whatever.
In the meantime I found a much less intrusive solution (hd-idle) that
just monitors /proc/diskstats for selected devices instead of trying
to replace periodic writeback wholesale.

cheers
Holger