Через сколько секунд буферы записи файловой системы обычно очищаются?
Прежде чем перезаписывать данные в файле, я хотел бы быть уверен, что старые данные хранятся на диске. Это потенциально очень большой файл (несколько ГБ), поэтому необходимы обновления на месте. Обычно размер записи составляет 2 МБ или более (мой план - использовать размер блока 4 КБ).
Вместо (или в дополнение к) вызова функции fsync() я хотел бы сохранить (не перезаписать) старые данные на диске до тех пор, пока файловая система не запишет новые данные. Основные причины, по которым я не хочу полагаться на fsync(): большинство жестких дисков лгут вам о выполнении fsync.
Итак, что я ищу, так это то, какова типичная максимальная задержка для файловой системы, операционной системы (например, Windows), жесткого диска, пока данные не будут записаны на диск, без использования fsync или аналогичных методов. Я хотел бы иметь реальные цифры, если это возможно. Я не ищу совет, чтобы использовать fsync.
Я знаю, что нет 100% надежного способа сделать это, но я хотел бы лучше понять, как работают операционные системы и файловые системы в этом отношении.
На данный момент я обнаружил, что 30 секунд является / было значением по умолчанию для / proc / sys / vm / dirty_expire_centiseconds. Затем " грязные страницы сбрасываются (записываются) на диск... (когда) слишком много времени прошло с тех пор, как страница оставалась грязной" (но там я не смог найти время по умолчанию). Так что для Linux 40 секунд кажутся безопасными. Но так ли это для всех файловых систем / дисков? А как насчет Windows, Android и так далее? Я хотел бы получить ответ, который относится ко всем распространенным операционным системам / файловым системам / типам дисков, включая Windows, Android, обычные жесткие диски, твердотельные накопители и т. Д.
4 ответа
Позвольте мне перефразировать вашу проблему лишь в несколько неоправданных терминах: вы пытаетесь контролировать поведение физического устройства, которое не может контролировать его драйвер в операционной системе. То, что вы пытаетесь сделать, кажется невозможным, если то, что вы хотите, является реальной гарантией, а не довольно хорошим предположением. Если все, что вы хотите, это довольно хорошее предположение, хорошо, но остерегайтесь этого и документируйте соответственно.
Вы можете решить эту проблему с помощью правильного драйвера устройства. Протокол SCSI, например, имеет Force Unit Access (FUA) немного в своем READ а также WRITE Команды, которые инструктируют устройство обойти любой внутренний кеш. Даже если данные изначально были записаны как буферизованные, чтение без буферизации должно быть в состоянии убедиться, что они действительно были там.
Единственный способ надежно убедиться, что данные синхронизированы, - это использовать механизм синхронизации, специфичный для ОС, и в соответствии с Документами по надежности PostgreSQL.
Когда операционная система отправляет запрос на запись в оборудование хранения, мало что можно сделать, чтобы убедиться, что данные поступили в действительно энергонезависимую область хранения. Скорее, администратор обязан убедиться, что все компоненты хранилища обеспечивают целостность данных.
Так что нет, по-настоящему портативных решений нет, но можно (но сложно) написать переносимые оболочки и развернуть надежное решение.
Прежде всего, спасибо за информацию, что жесткие диски лгут о сбрасывании данных, что было для меня новым.
Теперь к вашей проблеме: вы хотите быть уверены, что все данные, которые вы пишете, были записаны на диск (самый низкий уровень). Вы говорите, что есть две части, которые необходимо контролировать: время, когда операционная система записывает данные на жесткий диск, и время, когда жесткий диск записывает данные на диск.
Ваше единственное решение - использовать таймер с нечеткой логикой, чтобы оценить, когда будут записаны данные.
На мой взгляд, это неправильный путь. Вы можете контролировать, когда операционная система записывает данные на жесткий диск, поэтому используйте эту возможность и управляйте ею! Тогда только лежачий жесткий диск - ваша проблема. Эта проблема не может быть решена надежно. Я думаю, вы должны сказать пользователю / администратору, что он должен позаботиться о выборе правильного жесткого диска. Конечно, было бы неплохо реализовать предложенный вами дополнительный таймер.
Я считаю, что вы должны начать ряд тестов с различными жесткими дисками и инструментом Брэда Фицджеральда, чтобы получить точную оценку того, когда жесткие диски будут записывать все данные. Но конечно - если жесткий диск хочет врать, вы никогда не сможете быть уверены, что данные действительно были записаны на диск.
Это старый вопрос, но он все еще актуален в 2019 году. Для Windows ответ выглядит "по крайней мере каждые одну секунду" на основании следующего:
Чтобы обеспечить правильную очистку, диспетчер кеша каждую секунду запускает процесс, называемый ленивой записью. Процесс отложенной записи ставит в очередь одну восьмую страниц, которые не были сброшены в последнее время, для записи на диск. Он постоянно переоценивает объем сбрасываемых данных для оптимальной производительности системы и, если необходимо записать больше данных, помещает в очередь больше данных.
Чтобы быть ясным, выше сказано, что ленивый писатель порождается каждую секунду, что не то же самое, что записывать данные каждую секунду, но это лучшее, что я могу найти до сих пор в моем собственном поиске ответа на аналогичный вопрос (в В моем случае у меня есть приложения для Android, которые лениво записывают данные обратно на диск, и я заметил некоторую потерю данных при использовании интервала в 3 секунды, поэтому я собираюсь уменьшить его до 1 секунды и посмотреть, поможет ли это... это может ухудшают производительность, но потеря данных убивает производительность намного больше, если учесть часы, которые потребуются для их восстановления).
Существует множество кешей, которые дают пользователям адаптивную систему.
Имеется кэш процессора, кэш памяти ядра / файловой системы, кэш памяти дисковода и т. Д. Что вы спрашиваете, сколько времени занимает очистка всех кешей?
Или, с другой стороны, что произойдет, если диск выйдет из строя? Вся очистка не гарантирует успешную операцию чтения или записи.
Дисководы со временем портятся. Решение, которое вы ищете, заключается в том, каким образом вы можете использовать избыточную систему процессора / дисковода, чтобы система выдержала сбой компонента и продолжала работать.
Вы можете повысить вероятность того, что система будет продолжать работать с помощью аппаратного обеспечения, такого как RAID-массивы и другие конфигурации высокой доступности.
Что касается программного решения, я думаю, что ответ заключается в том, чтобы доверить ОС оптимальную работу. Большинство из них регулярно очищают буферы.