Безопасность записи в кэш на дисках SATA с барьерами

В последнее время я читал о кэшировании записи, NCQ, ошибках прошивки, барьерах и т. Д. В отношении накопителей SATA, и я не уверен, какова наилучшая настройка, которая обеспечивала бы безопасность моих данных в случае сбоя питания.

Насколько я понимаю, NCQ позволяет приводу переупорядочивать записи для оптимизации производительности, в то же время информируя ядро ​​о том, какие запросы были физически записаны.

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

Я не уверен, как NCQ и Write кеш смешиваются здесь ...

Файловые системы, особенно журналируемые, должны быть уверены, что конкретный запрос записан. Кроме того, процесс пользовательского пространства использует fsync () для принудительной очистки определенного файла. Этот вызов fsync () не должен возвращаться, пока файловая система не будет уверена, что данные записаны на диск.

Есть функция (FUA, Force Unit Access), которую я видел только на дисках SAS, которая заставляет диск обходить кэш и записывать данные прямо на диск. Для всего остального есть барьеры записи - механизм, предоставляемый ядром, который может инициировать очистку кеша на диске. Это заставляет записывать весь кеш, а не только критические данные, что замедляет работу всей системы, например, с помощью fsync ().

Тогда есть диски с ошибками прошивки, или которые намеренно лгут о том, когда данные были физически записаны.

Сказав это ... есть несколько способов настроить диски / файловые системы: A) NCQ и кэш записи отключен B) Просто NCQ включен C) Просто кэш записи включен D) Включен NCQ и кэш записи

Я предполагаю, что барьеры включены .. Кстати, как проверить, действительно ли они включены?

В случае потери питания при активной записи на диск, я предполагаю, что опция B (NCQ, без кэша) безопасна как для журнала файловой системы, так и для данных. Там может быть снижение производительности.

Вариант D (NCQ + кеш), если используются барьеры или FUA, будет безопасен для журнала файловой системы и приложений, использующих fsync (). Это было бы плохо для данных, ожидающих в кеше, и файловая система должна обнаружить их (проверка контрольных сумм), и, по крайней мере, файловая система не будет (надеюсь) в нестабильном состоянии. По производительности, это должно быть лучше.

Мой вопрос, однако, стоит ... Я что-то упустил? Есть ли какая-либо другая переменная, чтобы принять во внимание? Есть ли какой-нибудь инструмент, который мог бы подтвердить это, и что мои диски ведут себя так, как должны?

Для корпоративных систем Enterprise есть дополнительный уровень в виде адаптера хранения (почти всегда карты RAID), на котором существует еще один уровень кэша. Существует много абстракции в хранилище укладывают в эти дни, и я вошел в глубокую подробно это в серии блоге я сделал на Know ваш I / O .

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

Некоторые корпоративные твердотельные накопители включают встроенный конденсатор с достаточной скоростью, чтобы зафиксировать встроенный кэш перед полным отключением питания.

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

Однако время шло, и XFS была разработана, чтобы выжить. Другие основные файловые системы Linux (а также ntfs в Windows) уже были разработаны, чтобы выжить в этом же режиме отказа. Предполагается, что потерянные записи не будут отображаться в журнале FS, и он будет знать, что они не были обработаны, поэтому коррупция будет надежно обнаружена и устранена.

Вы указываете на одну проблему здесь: прошивка диска, которая лежит. В этом случае журнал FS сделает неверное предположение относительно реальности, и коррупция может не обнаруживаться в течение некоторого времени. RAID четности и зеркальный RAID могут обойти эту проблему, так как должна быть еще одна назначенная копия для извлечения. Но в настройках одного диска такой перекрестной проверки не будет, поэтому на самом деле произойдет сбой.

Вы справляетесь с риском микропрограммного обеспечения, используя накопители корпоративного уровня, которые проходят гораздо более тщательную проверку (и тестируются по сравнению с предполагаемыми образцами рабочей нагрузки), и проектируя свою систему хранения так, чтобы она могла выдержать такую ​​неправду.

Журнал файловой системы первоначально ожидал завершения записи в журнал, прежде чем отправлять запись в метаданные, предполагая, что не было кэша записи на диск. При включенном кэшировании записи на диск это предположение нарушается и может привести к потере данных. Таким образом, барьеры были созданы. С помощью барьеров журнал может убедиться, что запись в журнал завершена до записи в метаданные, даже если диск использует кэширование записи. На уровне драйвера диска барьер вызывает очистку дискового кэша перед отправкой последующего ввода-вывода, когда накопитель сообщает, что у него есть кэш записи и он включен. В противном случае это не требуется, поэтому барьер просто предотвращает выдачу последующего ввода-вывода на накопитель до завершения предыдущего ввода-вывода. NCQ просто означает, что, возможно, придется подождать более одного ожидающего запроса для завершения, прежде чем выдать больше.