В последнее время я читал о кэшировании записи, NCQ, ошибках прошивки, барьерах и т. Д., Касающихся дисков SATA, и я не уверен, какой лучший параметр обеспечит безопасность моих данных в случае сбоя питания.
Насколько я понимаю, NCQ позволяет приводу переупорядочивать записи для оптимизации производительности, сохраняя при этом информацию ядру о том, какие запросы были физически записаны.
Кэш записи позволяет накопителю обрабатывать запрос намного быстрее, потому что он не ждет, пока данные будут записаны на физический диск.
Я не уверен, как здесь сочетаются NCQ и Write cache ...
Файловые системы, особенно журналируемые, должны быть уверены, что конкретный запрос был записан. Кроме того, процесс пользовательского пространства использует fsync () для принудительной очистки определенного файла. Этот вызов fsync () не должен возвращаться, пока файловая система не будет уверена, что данные записаны на диск.
Есть функция (FUA, Force Unit Access), которую я видел только на дисках SAS, которая заставляет диск обходить кеш и записывать непосредственно на диск. Для всего остального существуют барьеры записи, которые представляют собой механизм, предоставляемый ядром, который может запускать очистку кеша на диске. Это заставляет все записывать в кеш, а не только критически важные данные, что замедляет работу всей системы в случае злоупотребления, например, с помощью fsync ().
Кроме того, есть диски с ошибками прошивки, или диски, которые намеренно лгут о том, когда данные были физически записаны.
Сказав это ... есть несколько способов настроить диски / файловые системы: A) NCQ и кэш записи отключены B) Включено только NCQ C) Включено только кеширование записи D) Включены как NCQ, так и кеш записи
Я предполагаю, что барьеры включены .. Кстати, как проверить, действительно ли они включены?
В случае потери питания при активной записи на диск, я предполагаю, что вариант B (NCQ, без кеша) безопасен как для журнала файловой системы, так и для данных. Может быть снижение производительности.
Вариант D (NCQ + cache) при использовании барьеров или FUA будет безопасным для журнала файловой системы и приложений, использующих fsync (). Это будет плохо для данных, которые ожидают в кеше, и файловая система должна их обнаружить (проверка), и, по крайней мере, файловая система не будет (надеюсь) в нестабильном состоянии. По производительности должно быть лучше.
Однако мой вопрос остается в силе ... Я что-то упускаю? Следует ли учитывать какие-либо другие переменные? Есть ли какой-нибудь инструмент, который мог бы подтвердить это, и что мои диски ведут себя так, как должны?
Для обычных корпоративных систем существует дополнительный уровень в виде адаптера хранилища (почти всегда карта RAID), на котором существует еще один уровень кэша. В наши дни в стеке хранилища много абстракций, и я подробно рассмотрел это в своей серии блогов, посвященной Знай свой ввод / вывод.
Карты RAID могут обходить кеш-память на диске, некоторые из которых даже позволяют переключать эту функцию в RAID BIOS. Это одна из причин, почему Enterprise диски являются Enterprise, их прошивка позволяет делать такие вещи, которые потребительские диски (особенно «зеленые» диски) нет. Эта функция напрямую касается случая, который вас беспокоит: сбой питания с невыполненной записью. Кэш карты RAID, который должен быть либо от аккумулятора, либо с резервной памятью, будет сохранен до тех пор, пока не будет восстановлено питание и эти операции записи не будут выполнены повторно.
Некоторые корпоративные твердотельные накопители включают встроенный конденсатор с мощностью, достаточной для фиксации встроенного кэша перед полным отключением питания.
Если вы работаете с системой с дисками, напрямую подключенными к материнской плате, гарантий меньше. Если сами диски не имеют возможности фиксировать кэш записи, сбой питания действительно приведет к потере. В xfs файловая система заслужила репутацию ненадежной из-за невозможности выжить только в этом режиме отказа; он был разработан для работы в полнофункциональных корпоративных системах с повышенной живучестью систем хранения.
Однако время шло, и XFS была разработана, чтобы пережить это. Другие основные файловые системы Linux (а также NTFS в Windows) уже было инженерии, чтобы выжить в этом самом режиме отказа. Предполагается, что это работает так: потерянные записи не будут отображаться в журнале FS, и он будет знать, что они не были выполнены, поэтому коррупция будет безопасно обнаружена и устранена.
Вы действительно указываете на одну проблему: которая лежит на диске. В этом случае журнал FS сделает неверное предположение по сравнению с реальностью, и повреждение может не обнаруживаться в течение некоторого времени. RAID с контролем четности и зеркальный RAID могут обойти это, так как должна быть еще одна созданная копия, из которой можно извлечь. Но в настройках с одним диском такой перекрестной проверки не будет, так что на самом деле будет ошибка.
Вы можете избежать риска, связанного с микропрограммным обеспечением, используя диски корпоративного уровня, которые проходят гораздо более тщательную проверку (и проверяются на соответствие вашим предполагаемым шаблонам рабочих нагрузок), и спроектировав свою систему хранения таким образом, чтобы она могла выдержать такую неправду.
Журнал файловой системы изначально ожидал завершения записи в журнал, прежде чем выполнять запись в метаданные, предполагая, что кеш записи на диск отсутствует. При включенном кэшировании записи на диск это предположение нарушается и может привести к потере данных. Таким образом были созданы преграды. С помощью барьеров журнал может гарантировать, что запись в журнал завершится до записи в метаданные, даже если диск использует кэширование записи. На уровне драйвера диска барьер вызывает очистку кеша диска перед отправкой последующих операций ввода-вывода, когда диск сообщает, что у него есть кэш записи и он включен. В противном случае в этом нет необходимости, поэтому барьер просто предотвращает отправку последующего ввода-вывода на диск, пока не завершится предыдущий ввод-вывод. NCQ просто означает, что ему, возможно, придется дождаться завершения более чем одного ожидающего запроса, прежде чем выдать еще.