Исправление bugfixer, (текущая версия) :
Зато в XFS - ничего этого нет от слова совсем. Без полного sync’а - никто не гарантирует ничерта от слова совсем.
Они (libc/kernel/fs) должны правильно обрабатывать fsync/fdatasync, больше от них требовать ничего нельзя в этом плане. Существует несколько уровней буферизации (иначе все было бы очень и очень медленно), и до fsync/fdatasync/fclose (если вы работаете на уровне FILE* а не непосредственно на дескрипторе) даже нельзя быть уверенным что ядро вообще увидело ваши данные. Дальше хуже - даже если libc / kernel / fs / driver честно сделали свою работу данные могут сидеть в cache диска сколь угодно долго (хотя так конечно никто не делает). Поэтому и существует низкоуровневая ATA комманда FUA которая приказывает диску сбросить свой cache. Но и с ней не все так просто - если у Вас серьезный дисковый контроллер с собственным cache подпёртым батарейкой он наверняка подтвердит FUA мгновенно в предположении что даже при внезапной потере питания оно вернется в течении максимум 24-72 часов и тогда он завершит все uncommitted writes (сильно ускоряет DB-like workloads). Как то так. В общем делайте ручками sync почаще и будет вам счастье ;)
Исправление bugfixer, :
Зато в XFS - ничего этого нет от слова совсем. Без полного sync’а - никто не гарантирует ничерта от слова совсем.
Они (libc/kernel/fs) должны правильно обрабатывать fsync/fdatasync, больше от них требовать ничего нельзя в этом плане. Существует несколько уровней буферизации (иначе все бы было очень и очень медленно), и до fsync/fdatasync/fclose (если вы работаете на уровне FILE* а не непосредственно на дескрипторе) даже нельзя быть уверенным что ядро вообще увидело ваши данные. Дальше хуже - даже если libc / kernel / fs / driver честно сделали свою работу данные могут сидеть в cache диска сколь угодно долго (хотя так конечно никто не делает). Поэтому и существует низкоуровневая ATA комманда FUA которая приказывает диску сбросить свой cache. Но и с ней не все так просто - если у Вас серьезный дисковый контроллер с собственным cache подпёртым батарейкой он наверняка подтвердит FUA мгновенно в предположении что даже при внезапной потере питания оно вернется в течении максимум 24-72 часов и тогда он завершит все uncommitted writes (сильно ускоряет DB-like workloads). Как то так. В общем делайте ручками sync почаще и будет вам счастье ;)
Исправление bugfixer, :
Зато в XFS - ничего этого нет от слова совсем. Без полного sync’а - никто не гарантирует ничерта от слова совсем.
Они (libc/kernel/fs) должны правильно обрабатывать fsync/fdatasync, больше от них требовать ничего нельзя в этом плане. Существует несколько уровней буферизации (иначе все бы было очень и очень медленно), и до fsync/fdatasync/fclose даже нельзя быть уверенным что ядро вообще увидело ваши данные. Дальше хуже - даже если libc / kernel / fs / driver честно сделали свою работу данные могут сидеть в cache диска сколь угодно долго (хотя так конечно никто не делает). Поэтому и существует низкоуровневая ATA комманда FUA которая приказывает диску сбросить свой cache. Но и с ней не все так просто - если у Вас серьезный дисковый контроллер с собственным cache подпёртым батарейкой он наверняка подтвердит FUA мгновенно в предположении что даже при внезапной потере питания оно вернется в течении максимум 24-72 часов и тогда он завершит все uncommitted writes (сильно ускоряет DB-like workloads). Как то так. В общем делайте ручками sync почаще и будет вам счастье ;)
Исходная версия bugfixer, :
Зато в XFS - ничего этого нет от слова совсем. Без полного sync’а - никто не гарантирует ничерта от слова совсем.
Они (libc/kernel/fs) должны правильно обрабатывать fsync/fdatasync, больше от них требовать ничего нельзя в этом плане. Существует несколько уровней буферизации (иначе все бы было очень и очень медленно), и до fsync/fdatasync/fclose даже нельзя быть уверенным что ядро вообще увидело ваши данные. Дальше хуже - даже если libc / kernel / fs / driver честно сделали свою работу данные могут сидеть в cache диска сколь угодно долго (хотя так конечно никто не делает). Поэтому и существует низкоуровневая ATA комманда FUA которая приказывает диску сбросить свой cache. Но и с ней не все так просто - если у Вас серьезный дисковый контроллер с собственным cache подпёртым батарейкой он наверняка подтвердит FUA мгновенно в предположении что даже при внезапной потере питания оно вернется в течении 24-72 и тогда он завершит все uncommitted writes (сильно ускоряет DB-like workloads). Как то так. В общем делайте ручками sync почаще и будет вам счастье ;)