2013-12-11 2 views
2

Очевидно, что кеш-файл Windows сбрасывает данные на диск асинхронно, даже при использовании синхронного API WriteFile(). Цитирование "File Caching" on MSDN:Какие ошибки могут возникнуть при сбое диска с файловым кэшем системного файла (Windows)? как они сообщаются?

По умолчанию, [...] операции записи записи данных файлов в кэш файловой системы , а не на диске, и этот тип кэша называется кэш обратной записи.

Если предположить, что записи через и не буферные флаги не используются, что произойдет, если фактическая запись на диск не удастся? Могут ли клиенты получать уведомления о таких сбоях? Какова ожидаемая модель обработки ошибок клиента для таких сбоев? «Огонь и забыть» и «Написать и молиться» приходят на ум, но, возможно, есть что-то еще.

Второй вопрос: существуют ли определенные классы ошибок, которые гарантированно будут обнаружены раньше? Например. будет ли WriteFile() всегда возвращать ошибку, если диск заполнен? - даже если фактическая запись на диск будет отложена?

Я хотел бы знать, как писать надежный файл, который отвечает на эти ошибки, не отключая Файловый кэш Windows.

Бонусные баллы: обрабатывается ли это по-другому в других операционных системах? Можете ли вы порекомендовать хороший ресурс по этой теме?

+2

Клиент может закрыть дескриптор файла и выйти до того, как произойдет реальная запись на диск, поэтому разумно, что в этой ситуации нет обратной связи с клиентом. Он обрабатывается на более низком уровне. –

+0

Даже * с * установленными флажками записи и без буферизации, диск может лежать о том, действительно ли он передал данные на диск; он все равно может находиться в буферном кеше на самом диске (или на RAID-контроллере). –

+0

@ EricBrown Да, была [интересная ссылка относительно этого] (http://disruptivesql.wordpress.com/2012/05/08/sata-and-write-through/), размещенная на странице MSDN, о которой я упоминал. Мой вопрос об ошибках и сообщениях об ошибках на уровне Windows. Предположительно, лёгкие диски имеют довольно высокую уверенность в своей способности в конечном итоге передавать данные на диск (отключение электроэнергии). Не знаете, как ОС может сделать такие предположения. –

ответ

2

В Windows 7 пользователь уведомляется через всплывающее диалоговое окно из области уведомлений.

Нормальные ошибки (такие как заполненный диск, отсутствие разрешений и т. Д.) Немедленно возвращаются в приложение, это не вызывает поздних сбоев.

Поздние сбои могут произойти только в нескольких ситуациях, таких как сбой аппаратного обеспечения или сбоя операционной системы. Они также могут возникать при записи в сетевой ресурс, если соединение по какой-либо причине неожиданно неожиданно падает.

В большинстве случаев для приложения не имеет смысла беспокоиться об этом. В этих обстоятельствах следует ожидать потери данных; пусть пользователь справится с этим.

Если данные, которые вы пишете, необычайно важны, вам может потребоваться беспокоиться, и в этом случае вам придется использовать флажки для записи и/или отсутствия буферизации.

Третьего варианта нет.

+0

Спасибо, Гарри, это очень полезный и ясный ответ. Могу ли я спросить, как вы знаете эту информацию? Это где-то задокументировано? –

+0

Опыт. Windows, к сожалению, далеко не полностью документирована; возможно, учитывая его размер и сложность, было бы невозможно сделать это, конечно, было бы невозможно. С другой стороны, Microsoft прилагает весьма экстремальные меры для обеспечения совместимости с любым широко зависимым поведением, поэтому (как неудовлетворительно, как это может быть с точки зрения компьютерной науки) практический подход к ответу на этот вопрос заключается в том, чтобы спросить вместо этого «Что делают все остальные?» –

+0

(Основное понимание того, что представляют собой компоненты ОС и как они взаимодействуют, т. Е. Знание того, что NTFS лежит поверх кеша, в сочетании с пониманием общей структуры тома NTFS дает понять, что кеширование не может скрыть полное состояние диска.) –

Смежные вопросы