Как производится запись при помощи системного вызова write

Мне непонятно, после какого вызова я могу быть твердо уверен, что данные записаны не в буфер HDD, а непосредственно на сам HDD.

Теоретически для этого сделан флаг O_DIRECT для функции open, но и с его помощью ты не всегда можешь быть уверен в 100% записи. Но, кажется, это максимум - что ты можешь добиться для обычной прикладной программы.

а в общем практически правильно, если по точнее, то в начале идет буферизация языка программирования, далее буферизация используемого фреймворка, далее буферизация *libc, далее драйвера ядра-файловой системы, далее ядро-возможных оверлеев и т.д., далее ядро-поддержка блочного устройства, ядро-поддержка конкретного SATA/MD/LVM и т.д. далее уже буферы железа.

в общем когда байты дойдут до блина HDD - они уже весьма постареют =))

данные записаны не в буфер HDD, а непосредственно на сам HDD.

А ты хорош!

Это практически Ахилес и Черепаха. Мы никогда не сможем записать байты непосредственно на пластину. Так и будут они переходить из буфера верхнего уровня в буфер нижнего уровня, пока само течение времени не затихнет в вечности.

никого не слушай…

Мне непонятно, после какого вызова я могу быть твердо уверен, что данные записаны не в буфер HDD, а непосредственно на сам HDD

man fsync

И правильно, нефиг мне диски портить своими программами.

В общем мне кажется, я понимаю, что гарантий то прям записи в железку быть не может, и где-то использовали специальные жесткие диски с батарейкой, которые в случае обрыва по питанию, что-то там дописывали, но вот в очередной раз столкнулся и захотелось уж ОКОНЧАТЕЛЬНО РАЗОБРАТЬСЯ.

Тебя ждёт много проблем

Проблемы надёжной доставки данных до постоянного хранилища и fsync()

после какого вызова я могу быть твердо уверен, что данные записаны не в буфер HDD, а непосредственно на сам HDD

в теории после вызова fsync. Как правило этого хватает, но иногда если совсем хочется быть уверенным, стоит прочитать, правда прочитаешь из кеша.

Для «окончательно разобраться» используют fsync(). Если он реализован правильно, то есть возвращается только после физической записи на диск всех забуферизованных изменений в файловой системе, то он может считаться надёжной точкой невозврата.

Бывают неправильно реализованные fsync(), которые могут работать так же как write() - забуферизовать и сказать что мамой клянусь всё записалось, а на самом деле не записать. Например считается, что RAID-контроллер имеет своё питание и диски имеют своё питание и всё что попало в буфер RAID-контроллера - точно запишется, но потом. Тогда fsync() возвращается, а запись будет когда-то потом. Это пример «неправильного» fsunc() – на этом этапе надо разобраться какой у тебя, почитать какие-то спеки на систему, незнаю… Незнаю какой флаг и где в системе посмотреть, чтобы отличить нормальный fsync() от либерально-демократического.

У fsync() главное свойство - барьер - всё, что было write() после этого fsync() - оно запишется на диск точно позже, чем то, что было write() перед этим fsync(). Это ключевое средство упорядочения чего-то. Упорядочение - это важнейшая еболда в некоторых частях баз данных, без которых не получается гарантировать всю глубину глубин. Но нормальный fsync() должен вернуться только после того, как байтики физически контроллером диска/ssd будут на флешки/диски забодяжены все. Какие байтики - все, которые файловая система уже до этого момента успела отправить на запись.

Да fsync() - это не про байтики конкретного файла или блока или приложения или пользователя. Это про всю файловую систему сразу. Если вызвать fsync() на системе с медленным HDD, то вся система и все приложения, пытающиеся работать с диском, временно огребут заморозку и тормоза, потому что происходит дикий флаш на диск.

Тут ещё файловая система конечно как огромный промежуточный посредник фигурирует, но это не важно - fsync() - он про файловую систему. Он делает так, что всё, что файловая система хотела на диске отразить, будет там физически отражено. Всё, что файловая система могла захотеть на диск подвезти после этого fsync() может совсем до диска не дойти или дойти наполовину - это уже журналы в журналируемых FS порешают, всё откатится, но записанное до fsync() откачено быть не может. В классической реализации. То есть, это любой ноутбук с убунтой. fsync() может странно себя вести на странных системах - всякие там физические узкоспециальные системы хранения.

write это тонкая обертка над syscall, там нет никакой дополнительной буферизации, поэтому все идет напрямую в буфер ОС

Завершение write гарантирует, что данные из юзерспейса (указатель на которые и длину которых ты передал в этот вызов) скопированы в блочный кэш ядра. Память в юзерспейсе после завершения write можно освобождать.

Завершение fdatasync гарантирует, что данные из блочного кэша ядра, относящиеся к этому файлу (файловый дескриптор которого ты передал в этот вызов), отправлены в устройство, и от устройства получено подтверждение. Завершение fsync гарантирует, что устройству отправлены не только данные, но и метаданные файла (inode), и получено подтверждение от устройства.

Если ты создал новый файл, то ты тем самым создал запись каталога, и её fsync на файловый дескриптор файла на устройство не отправит. При создании нового файла или каталога, надо открыть родительский каталог open(dir, O_RDONLY|O_DIRECTORY) и на этот файловый дескриптор тоже сделать fsync.

В устройстве может быть свой буфер, и устройство может использовать его как в режиме write through (устройство подтверждает после копирования в буфер и записи на носитель), так и в режиме write back (устройство подтверждает после копирования в буфер). В протоколе SCSI у команды WRITE есть флажок FUA (Force Unit Access), чтобы конкретно эта команда WRITE была подтверждена устройством только после записи на носитель. https://www.kernel.org/doc/Documentation/block/writeback_cache_control.rst

fsync использует флаг FUA, поэтому обычно fsync достаточно, чтобы данные дошли до носителя. Но если устройство не SCSI, или оно игнорирует FUA (шибко умная двухголовая СХД, например), то его вряд ли можно заставить писать на носитель.

Если ты просто пользователь ОС, то sync/fsync/fsyncdata в зависимости от масштаба требований (только данные, ещё метаданные, вся фс). Другого сисколла чтобы этого достичь нет.

Если интересует сисадминская сторона, то все железки и ОС нужно проверять, выключать питание и смотреть что сломалось. Иначе наверняка никак не узнать, разве что почитать всякие инсайды от редхатов и всяких операторов датацентров. Железо может тысячами способов обманывать ОС и говорить что вот сейчас точно записало, или неправильно выполнять все эти синки. Но подозреваю это всё такая редкость, что на некоторую потерю данных уже можно и согласиться. Пишешь все операции в виде лога, потеряешь максимум пару последних.

Вроде прояснилось, всем спасибо за подробные объяснения.

твердо уверен, что данные записаны не в буфер HDD, а непосредственно на сам HDD

Если твердо - после перезагрузки с ресетом по питанию и последующего чтения.

Если не очень твердо, то если диски делали не совсем рукожопы, после fsync/fdatasync обычно можно надеяться, что данные попали на носитель.

Жаль тут нет смайла «снимаю шляпу». А как это все работает если я пишу на подмонтированную файловую систему самбы, тут вообще никаких гарантий?

По хорошему должны быть, то что фс работает через сеть не отменяет возможности на другой стороне дождаться такого же fsync и послать сигнал что теперь записано. Если оборвётся связь, то мы просто не узнаем записано или нет и получим ошибку сети. Если же получили сигнал, то там точно всё записано.

Но конкретно про самбу ничего не гарантирую, я не знаю, нужно читать её документацию.

Что ты несешь, боже