Безопасность записи в кэш на дисках 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(). Это было бы плохо для данных, ожидающих в кэше, и файловая система должна их обнаружить (проверять контрольную сумму), и, по крайней мере, файловая система не будет (надеюсь) в нестабильном состоянии. По производительности, это должно быть лучше.
Мой вопрос, однако, стоит... Я что-то упустил? Есть ли какая-либо другая переменная, чтобы принять во внимание? Есть ли какой-нибудь инструмент, который мог бы подтвердить это, и что мои диски ведут себя так, как должны?
2 ответа
Для корпоративных систем Enterprise есть дополнительный уровень в виде адаптера хранения (почти всегда карты RAID), на котором существует еще один уровень кэша. В наши дни в стеке хранения много абстракций, и я углубился в это в серии блогов " Знай свой ввод-вывод".
Карты RAID могут обходить кэш на диске, некоторые из которых даже позволяют включать эту функцию в RAID BIOS. Это одна из причин, по которой корпоративные диски являются корпоративными, их встроенное ПО допускает такие вещи, которых нет у потребительских дисков (особенно у "зеленых"). Эта функция напрямую решает проблему, которая вас беспокоит: сбой питания при некомпетентных записях. Кэш карты RAID, который должен быть либо батарейным, либо флэш-резервным, будет сохраняться до тех пор, пока не восстановится питание и эти записи не могут быть возобновлены.
Некоторые корпоративные твердотельные накопители включают встроенный конденсатор с достаточной скоростью, чтобы зафиксировать встроенный кэш перед полным отключением питания.
Если вы работаете с системой, в которой диски напрямую подключены к материнской плате, меньше гарантий. Если сами диски не смогут зафиксировать кэш записи, сбой питания действительно приведет к потере. Файловая система xfs заработала репутацию ненадежного из-за своей неспособности выжить только в этом режиме отказа; он был спроектирован для работы в полноценных корпоративных системах с надежной системой хранения.
Однако время шло, и XFS была разработана, чтобы выжить. Другие основные файловые системы Linux (а также ntfs в Windows) уже были разработаны, чтобы выжить в этом же режиме отказа. Предполагается, что потерянные записи не будут отображаться в журнале FS, и он будет знать, что они не были обработаны, поэтому коррупция будет надежно обнаружена и устранена.
Вы указываете на одну проблему: прошивка диска, которая лежит. В этом случае журнал FS сделает неверное предположение относительно реальности, и коррупция может не обнаруживаться в течение некоторого времени. RAID четности и зеркальный RAID могут обойти эту проблему, так как должна быть еще одна назначенная копия для извлечения. Но в настройках одного диска такой перекрестной проверки не будет, поэтому на самом деле произойдет сбой.
Вы справляетесь с риском микропрограммного обеспечения, используя диски корпоративного уровня, которые проходят гораздо более тщательную проверку (и тестируются по сравнению с вашими предполагаемыми образцами рабочей нагрузки), и проектируя свою систему хранения так, чтобы она могла выдержать такую неправду.
Журнал файловой системы первоначально ожидал завершения записи в журнал, прежде чем отправлять запись в метаданные, предполагая, что кеша записи на диск не было. При включенном кэшировании записи на диск это предположение нарушается и может привести к потере данных. Таким образом, барьеры были созданы. С помощью барьеров журнал может убедиться, что запись в журнал завершена до записи в метаданные, даже если диск использует кэширование записи. На уровне драйвера диска барьер вызывает очистку дискового кэша перед отправкой последующего ввода-вывода, когда накопитель сообщает, что у него есть кэш записи и он включен. В противном случае это не требуется, поэтому барьер просто предотвращает выдачу последующего ввода-вывода на накопитель до завершения предыдущего ввода-вывода. NCQ просто означает, что, возможно, придется ждать более одного ожидающего запроса для завершения, прежде чем выдать больше.