fsync что это

Ответ от Џровой Владимир[гуру]
Зря перешёл. Вырубят свет - и у тебя пропадут данные
Там не оттестирована отложенная запись как следует. Линус по этому поводу кстати высказывался:
В виду последних событий, когда многие люди обнаружили () пропадание и обнуление файлов в файловой системе ext4 после краха ОС, создатели ext4 высказались за идею включения в ядро новых системных вызовов, которые бы позволили безопасно работать с файлами.
Линус Торвальдс в списке рассылки ядра жестоко раскритиковал (ссылка) эти предложения и заявил, что большинство программистов никогда не будут этими новыми системными вызовами пользоваться, что они будут не стабильными и плохо оттестированными.
Цитата: "Поэтому вместо того, чтобы придумывать новые препятствия, которые никто не будет использовать, разработчики файловых систем должны нацеливаться на плохой "лишь бы работал" код, до тех пор пока не случилась самое большое несчастье. Потому что, хотите вы этого или нет, 99% программ именно так и написаны.
Тот неоспоримый факт, что люди не проверяют ошибки, которые возвращает системный вызов close() (закрытие файла и сброс "грязных" данных из кэша на диск) должен означать, что, например, при отложенной записи на диск нужно обязательно проверять ситуацию переполнения диска. Если ваша файловая система возвращает ENOSPC при закрытии файла через вызов close(), а не при записи в него через write(), значит, что вы потеряли обработку ошибок переполнения диска у 90% приложений. Вот так всё просто.
Жаловаться на то, что ошибка в приложении - это всё равно, что жаловаться на скорость света: вы должны иметь дело с реальным миром, а не с тем, каким бы вы хотели его видеть. То же самое относится к идее, что "люди должны писать во временный файл, вызывать функцию fsync для него и переименовывать его вместо оригинала". Вы думаете, что так должно быть, но в реалии программисты пишут open(filename, O_TRUNC O_CREAT, 0666). Это неправильно, я знаю. Но в конечном итоге, даже разработчики хорошо написанного приложения могут решить, что fsync() не стоит тех потерь в производительности. В git, например, где мы обычно пытаемся быть очень, очень и очень аккуратными, fsync() в объектных файлах по умолчанию выключен.
Почему? Потому что его включение вызывает неприемлемое поведение ext3. Сейчас, надо сказать, дизайн git'a рассчитан на то, что потеря нового БД файла не фатальна, но потенциально это очень беспокоит и смущает - вам, возможно, придётся откатить изменения назад и переделать некоторые операции вручную.
К чему я всё это говорю? Иногда те разработчики файловых систем, которые говорят "вы должны использовать fsync(), чтобы получить предсказуемые результаты" - это те же люди, которые испортили всё это до такого безобразия, что fsync'ом абсолютно нереально пользоваться.
Теория и практика иногда сталкиваются. Когда это случается, теория проигрывает. Всегда. "
URL:
Новость:
Яровой Владимир
Мастер
(1782)
Ну их нафиг, у мну работает 8.10 с ext3. Чего я буду экспериментировать на работающих компах?