Комментарии 2
Если очень кратко рассказать о самом важном, то получится, что для организации устойчивого хранения данных надо пользоваться командойfdatasync()или открывать файлы с флагомO_DSYNC
если рассматривать dc ssd (которые имеют power loss protection), то, как я понимаю, FUA приводит к потере производительности с минимальным повышением надёжности.
dc диск по спецификациям нам гарантирует, что отправленные на него данные не будут потеряны. однако, разумеется, эти гарантии не означают, что не может произойти сбой.
или гарантий диска нам достаточно, или нет.
во втором случае одним только FUA не обойтись, нужно делать резервирование с несколькими накопителями, контрольные суммы и всё такое.
Однако в большинстве программ для записи данных совершенно спокойно используются системные вызовы.
Вроде как все программы используют системные вызовы для io. А какие варианты?
Но write() лишь копирует данные приложения в кеш ядра,
Эта сущность называется Page cache. Оно конечно всё управляется ядром, но всё таки "кэш ядра" звучит так себе. Вероятно не нужно выдумывать новые термины, тема и без того сложная.
… надо пользоваться командой fdatasync()
Это всё же функция, команда обычно звучит, как sync, и у нее уже есть опции. Впрочем, не во всех версиях.
… Означает ли это, что операция write() является атомарной? С технической точки зрения — да.
Ну как бы нет. Либо расскажите, что вы понимаете тут под атомарностью? Вот rename, например, атомарна. А write, простите, абсолютно легко прерывается ядром посередине. То, что в один файл можно писать из кучи потоков/процессов — к атомарности операции отношения не имеет.
Если честно, еще много что режет глаз, но замолкаю. Реально тема интересная, но, простите, материал подан… неряшливо, чтоли. И много неточностей. Не обижайтесь.
Устойчивое хранение данных и файловые API Linux