История изменений

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

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

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

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

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

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

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

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

Да fsync() - это не про байтики конкретного файла или блока или приложения или пользователя. Это про всю файловую систему сразу.

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

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

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

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

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

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

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

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

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

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

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

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

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

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