Существуют ли какие-либо гарантии сохранения при использовании файлов с отображенной памятью или простого Stream.Write

Вы можете позвонить FlushViewOfFile, который инициирует грязную запись страницы, а затем FlushFileBuffers, который согласно этой статье , гарантирует, что страницы были написаны.

Вызов FlushFileBuffers после каждой записи может быть «безопаснее», но это не рекомендуется. Вы должны знать, сколько потерь вы можете терпеть. Существуют шаблоны, которые ограничивают эту потенциальную потерю, и даже лучшие базы данных могут потерпеть неудачу при записи. Вам просто нужно вернуться к жизни с наименьшей возможной потерей , которая обычно требует некоторой регистрации с многофазной фиксацией.

Я полагаю, что можно открыть файл отображения памяти с помощью FILE_FLAG_NO_BUFFERING и FILE_FLAG_WRITE_THROUGH, но это высосет вашу пропускную способность. Я не делаю этого Я открываю отображенные в память файлы для асинхронного ввода-вывода, позволяя ОС оптимизировать пропускную способность за счет собственной реализации портов завершения асинхронного ввода-вывода. Это самая быстрая пропускная способность. Я могу терпеть потенциальную потерю, и смягчил соответственно. Мои отображенные в память данные представляют собой данные резервного копирования файлов ... и, если я обнаружу потерю, я смогу обнаружить и повторно создать резервную копию потерянных данных после устранения аппаратной ошибки.

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

Файловая система NTFS (и ext3-4) использует журнал транзакций для управления изменениями. Каждое изменение сохраняется в журнале, а затем сам журнал используется для эффективного изменения. За исключением катастрофических сбоев диска, файловая система спроектирована так, чтобы она соответствовала своим собственным структурам данных, а не вашей: в случае сбоя процедура восстановления решит, что откатиться, чтобы сохранить согласованность , В случае отката ваши «еще не записанные, но подлежащие записи» данные будут потеряны. Файловая система будет согласованной, а ваши данные - нет.

Кроме того, существует несколько других факторов: программные и аппаратные кэши вводят дополнительный уровень и, следовательно, точку отказа. Обычно операции выполняются в кеше, а затем сам кэш сбрасывается на диск. Драйвер файловой системы не будет видеть операции, выполненные «в» кэше, но мы увидим операции очистки. Это сделано из соображений производительности, поскольку жесткий диск является узким местом. Аппаратные контроллеры имеют батареи, которые гарантируют, что их собственный кэш может быть очищен даже в случае потери питания.

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

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

TxF - это способ смягчить проблему, но имеет несколько последствий, которые ограничивают контексты, в которых вы можете его использовать: например, он не работает на разных дисках или в общих сетях.

Чтобы быть ACID, вам нужно спроектировать свои структуры данных и / или то, как вы их используете, чтобы не полагаться на детали реализации. Например, Mercurial (инструмент управления версиями) всегда добавляет свои собственные данные в свой собственный журнал изменений. Существует множество возможных шаблонов, однако, чем больше гарантий вам нужно, тем больше технологий вы получите (и с какой привязкой).