Изменения

SATA and SCSI drives have two ways of flushing cache: FLUSH CACHE command and FUA (Force Unit Access) flag for writes. The first is an explicit flush, the second is an instruction to write the data directly to media. Первый — это явный сброс кэшаTo be more precise, второй — это указание записать операцию на диск, минуя кэш. Точнее, у there is FUA flag in SCSI оно есть/SAS, а с but the situation is unclear with SATA ситуация точно не ясна: в спецификации it's there in the NCQ бит FUA естьspec, но факту FUA большинством дисков вроде как не поддерживается и, соответственно, эмулируется ядром/контроллером (если контроллер не кривой)but in practice most drives don't support it.

По всей видимости, It seems that fsync() отправляет диску команду sends the FLUSH CACHE, а открытие файла с command and opening a file with O_SYNC устанавливает бит sets the FUA на все команды записиbit.

Есть ли разницаDoes it make any difference? Обычно нетUsually no. Но на некоторых контроллерах иBut sometimes, depending on the exact controller and/или с некоторыми настройками различия по неустановленным причинам встречаютсяor its configuration, there may be a difference. И тогда In this case '''fio -sync=1 и ''' and '''fio -fsync=1 начинают давать разные результаты — возможно, даже на порядки разные результаты''' start to give different results. In some cases drives just ignore one of the flush methods.

Кроме тогоIn addition to that, у дисков есть команда отключения кэшаSATA/SAS drives also have a cache disable command. Когда он отключен, запросы сброса (fsync) When you disable the cache Linux диску не отправляетstops sending flushes at all. Казалось бы, такой режим тоже должен быть эквивалентен выполнению It may seem that this should also result in the same performance as fsync и/или O_SYNC после каждой команды, but that's not the case either! SSDs with supercaps give '''much''' better performance with disabled cache. Но и это не всегда так! На SSD с конденсаторами (то есть серверных моделях с Advanced Power Loss Protection) при отключении кэша For example, Seagate Nytro 1351 gives you 288 iops-ы случайной записи часто вырастают на порядок with cache and 18000 iops without it (например, с 5000 до 40000!). Но не всегда, так как это, опять-таки, зависит от контроллера.

ПочемуWhy? По-видимому, потому, что команда It seems that's because FLUSH CACHE трактуется диском как «сбрось все кэши» (включая энергонезависимый)is interpreted by the drive as a "please flush all caches, а отключение кэша — как «отключи энергозависимый кэш» (а энергонезависимый можешь оставить включенным). Соответственноincluding non-volatile cache" command, запись со сбросом кэша становится медленнееand "disable cache" is interpreted as "please disable the volatile cache, чем просто отключённый кэшbut you may leave the non-volatile on if you want to". This makes writes with a flush after every write slower than writes with the cache disabled.

А что с What about NVMe? В NVMe разнообразие чуть меньше — возможность отключить кэш в спецификации не предусмотрена вообщеhas slightly less variability - there is no "disable cache" command in the NVMe spec at all, но точно так же есть команды but just as in the SATA spec there is the FLUSH CACHE и бит command and FUAbit. При этом по личным наблюдениям FUA часто игнорируется то ли дискомBut again, то ли based on the personal experience I can say that it seems that FUA is often ignored with NVMe either by Linux-омor by the drive itself, и <tt>thus '''fio -sync=1</tt> выдаёт с NVMe такие же результаты, как и без ''' gives the same results as '''fio -direct=1''' without any sync вообщеflags. <tt>'''-fsync=1</tt> при этом ведёт себя как надо и приземляет производительность туда, где ей самое место ''' performs correctly and lands the performance down to where it must belong (на десктопных NVMe — до тех же 1000—2000 1000-2000 iopsfor desktop NVMes).

P.S: Bluestore использует uses fsync. Filestore использует uses O_SYNC.