Based on test benchmark, this might need some more investigation, on HDD it seems to bring a good improvement.
benchmark.zip contains the config file, and script to run

sysbench 0.4 parameters (update_index)

sysbench --test=oltp --oltp-table-size=50000000 --mysql-host=localhost --mysql-db=sbtest --mysql-user=root --mysql-password= --db-driver=mysql 

--mysql-table-engine=innodb --max-time=300 --oltp-test-mode=complex --oltp-read-only=off --max-requests=0 --num-threads=NUM_THREADS

--oltp-point-selects=0 --oltp-simple-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --oltp-distinct-ranges=0 ^

--oltp-index-updates=1 --oltp-delete-inserts=0 --oltp-non-index-updates=0  --oltp-skip-trx=on --oltp-dist-type=uniform  run

relevant config settings

innodb_buffer_pool_size=20G

innodb_log_file_size=6G

innodb_log_buffer_size=100M 

innodb_doublewrite=0

innodb_flush_log_at_trx_commit=2

Results for 24 users, in TPS, for the above run shows about 2x increase in throughput for HDD

HDD

On Linux since kernel version 2.6.29, the type of the medium can be detected by querying a file like /sys/block/sda/queue/rotational.

We could introduce a flag fil_space_t::is_rotational, and only allow innodb_flush_neighbors=ON to take effect on files that reside on rotational media. The same flag could also be used in MDEV-15528 to choose between punching holes and overwriting data with zero bytes.

axel, I hope that you can test bb-10.4-marko on Linux. On HDD, the setting innodb_flush_neighbors (default ON) should continue to have a similar impact that wlad reported above.
On SSD, the setting innodb_flush_neighbors should have no impact, that is, we should never flush nearby dirty pages.

On my Linux system, /sys/block listed only nvme0n1. I additionally tested after plugging in USB devices. Both were reported as /sys/block/sd*/queue/rotational=1 even though only one of them is a hard disk, and the other is a memory card reader. I have earlier tested that a SATA SSD was reported as non-rotational.

Quoting the commit message:

For diagnostics, we introduce the column ON_SSD to the table INFORMATION_SCHEMA.INNODB_TABLESPACES_SCRUBBING. The table INNODB_SYS_TABLESPACES might seem more appropriate, but its purpose is to reflect the contents of the InnoDB system table SYS_TABLESPACES, which we would like to remove at some point.

In MDEV-22343 we plan to remove the internal InnoDB tables SYS_TABLESPACES and SYS_DATAFILES.

I just realized that MDEV-15528 removed the view INFORMATION_SCHEMA.INNODB_TABLESPACES_SCRUBBING altogether from 10.5. It would allow us to fix scrubbing (MDEV-8139) by making it part of the normal page flushing mechanism. Hence, no status information table was necessary.

ralf.gebhardt@mariadb.com and serg, perhaps we would like to retain INFORMATION_SCHEMA.INNODB_SYS_TABLESPACES even if we remove the system table in 10.6? We could include a column ON_SSD there already starting with 10.4, to allow smooth upgrades to 10.5 and later versions. Currently we basically have a regression in 10.5 that removed the ON_SSD attribute.

I think that we could export the ON_SSD attribute as part of MDEV-20400, in a new view INFORMATION_SCHEMA.INNODB_TABLES or similar that contains one row per table (or partition or subpartition).

A possible alternative might be to revive INFORMATION_SCHEMA.FILES, which was originally implemented for NDB, implemented in MySQL 5.7 for InnoDB’s CREATE TABLESPACE support, and reverted from MariaDB in MDEV-11426.

An even more natural alternative could be to extend the MDEV-14533 INFORMATION_SCHEMA.DISKS plugin with an Boolean column that discloses whether the device is rotational (traditional hard disk). After all, that is a property of storage media, not individual files.