ну вот например про семантику FLUSH в NVMe: https://nvmexpress.org/wp-content/uploads/NVM-Express-1_4b-2020.09.21-Ratified.pdf

If a volatile write cache is enabled (refer to section 5.21.1.6),then the Flush command shall commit data and metadata associated with the specified namespace(s) to non-volatile media.The flush applies to all commands for the specified namespace(s) completed by the controller prior to the submission of the Flush command.The controller may also flush additional data and/or metadata from any namespace

Применяется только к командам, завершённым до флуша

Хех, вот сколько вопросов нашли 😀

Ну ок. Это команда флуш в девайсе

А фсинк это сиськолл в ленупсе. Там может быть другое

Может

И влиять на фио

Поэтому кому надо пусть делают фсинк файл рейндж

А не просто фсинк

Мне кажется, линуксовый тоже так же работает

Но проверить надо бы

Судя по исходникам ядра (blkdev_fsync), оно сначала сбрасываетs пейджкэш блокдевайса (если он есть), а потом просто отправляет FLUSH, т.е. гарантии, что он отправится только после завершения всех предыдущих отправленных в девайс директ врайтов, таки нет

Значит я обосрался

Ну не прям уж обосрался

Так чуть-чуть какнул

С кем не бывает

Народ, а посоветуйте fs под мусорохранилку не персистентную, в приоритете - IOPS над кучей мелких файлов

NFS

Не, вопрос про локальную fs для него, упёрлись в jbd2 >90% при апгрейде с ubuntu 16.04 до 20.04

Можно отключить журнал, но раньше производительнее было с ним всё-таки. Хочется разобраться, что TRIGGERED эту проблему