Безпека кеша запису на дисках SATA з бар'єрами

Я нещодавно читав про кешування записів, NCQ, помилки вбудованого програмного забезпечення, бар'єри тощо щодо накопичувачів SATA, і не знаю, який найкращий параметр, який би зробив мої дані безпечними у разі відключення живлення.

З того, що я розумію, NCQ дозволяє накопичувачеві переупорядкувати записи, щоб оптимізувати продуктивність, зберігаючи ядро ​​в курсі, про які запити були написані фізично.

Кеш запису робить накопичувач набагато швидше обслуговувати запит, оскільки він не чекає, коли дані будуть записані на фізичний диск.

Я не впевнений, як кеш NCQ і Write змішується тут ...

Файлові системи, спеціально опубліковані в журналі, повинні бути впевнені, коли певний запит був записаний. Також процес користувальницького простору використовує fsync (), щоб примусити флеш певного файлу. Цей виклик fsync () не повинен повертатися, поки файлова система не переконається, що дані записуються на диск.

Є функція (FUA, Force Unit Access), яку я бачив лише на дисках SAS, яка змушує диск обходити кеш і записувати безпосередньо на диск. Для всього іншого є бар'єри для запису, це механізм, який надає ядро, яке може викликати помилку кешу на диску. Це змушує записувати весь кеш, а не лише критичні дані, тим самим уповільнюючи всю систему при зловживанні, наприклад, за допомогою fsync ().

Потім з'являються накопичувачі з помилками вбудованого програмного забезпечення або навмисно брешуть, коли дані фізично записані.

Сказавши це .. Є кілька способів налаштування накопичувачів / файлових систем: A) NCQ і кеш запису вимкнено B) Просто включений NCQ C) Просто ввімкнено кеш запису D) Увімкнено кеш запису і кеш запису

Я вважаю, що бар'єри включені .. До речі, як перевірити, чи вони фактично включені?

У разі втрати живлення, під час активного запису на диск, я здогадуюсь, що варіант B (NCQ, без кеша) безпечний як для журналу файлової системи, так і для даних. Може бути пені за виконання.

Варіант D (кеш-пам'ять NCQ +), якщо використовується бар'єр або FUA, буде безпечним для журналу файлової системи та додатків, які використовують fsync (). Це було б погано для даних, які чекали в кеш-пам'яті, і файлова система залежить від її виявлення (контрольна сума), і принаймні файлова система не буде (сподіваємось) у нестабільному стані. Виконання продуктивності, воно повинно бути кращим.

Однак моє запитання стоїть ... Я чогось не пропускаю? Чи варто враховувати якусь іншу змінну? Чи є інструмент, який міг би це підтвердити, і що мої диски поводяться як слід?

Для прямих систем Enterprise існує додатковий шар у вигляді адаптера для зберігання даних (майже завжди RAID-карта), на якому існує ще один шар кешу. Сьогодні у стеку зберігання є багато абстракцій, і я детально детально описував це в серії блогу, який я робив на " Знаю ваш I / O" .

Карти RAID можуть обходити кеш диска, деякі з яких навіть дозволяють переключити цю функцію в RAID BIOS. Це одна з причин, чому диски Enterprise є Enterprise, а їх вбудована програма дозволяє такі речі, на яких споживчі диски ( особливо "зелені" диски) цього не роблять. Ця функція безпосередньо стосується випадку, який вас хвилює: відключення живлення з невмілим записом. Кеш карти RAID, який має бути акумулятором або захищеним від спалаху, зберігатиметься до повернення живлення та відновлення записів.

Деякі фірмові SSD включають в себе вбудований конденсатор з достатньою кількістю oomph, щоб здійснити вбудований кеш, перш ніж повністю вимкнути живлення.

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

Однак час пішов і XFS був розроблений, щоб пережити це. Інші основні файлові системи Linux (як і ntfs в Windows) вже мали інженерію, щоб пережити цей самий режим відмови. Як це має працювати, так це те, що втрачені записи не відображатимуться в журналі FS, і буде відомо, що вони не були порушені, тож корупція буде безпечно виявлена ​​та оброблена.

Ви вказуєте на одну проблему тут: прошивку диска, яка лежить. У цьому випадку журнал FS зробив неправильне припущення щодо реальності, і корупція може не виявлятися протягом деякого часу. Паритет RAID та дзеркальний RAID можуть обійти це, оскільки має бути ще одна копійована копія. Але в налаштуваннях одного диска не буде такої перехресної перевірки, тому насправді виникла помилка.

Ви долаєте ризик вбудованого програмного забезпечення, використовуючи накопичувачі Enterprise-класу, які отримують набагато більшу валідацію (і тестуються у порівнянні з вашими передбачуваними моделями навантаження) та проектуючи вашу систему зберігання, щоб вона могла пережити такі неправди.

Журнал файлової системи спочатку чекав завершення запису до журналу перед тим, як надрукувати запис у метадані, припускаючи, що кеш запису диска не було. Якщо ввімкнено кешування запису на диску, це припущення порушено і може призвести до втрати даних. Таким чином, були створені бар'єри. Маючи бар'єри, журнал може переконатися, що запис до журналу завершиться перед записом у метадані, навіть якщо на диску використовується кешування запису. На рівні драйверів диска бар'єр змушує змивати кеш диска до наступного надсилання IO, коли привід повідомляє, що у ньому є кеш запису, і він увімкнено. В іншому випадку це не потрібно, тому бар'єр просто перешкоджає видачі наступного вводу-виводу на накопичувач, поки попередній IO не завершиться. NCQ просто означає, що, можливо, доведеться зачекати, поки не буде виконано більше одного очікуваного запиту, перш ніж надсилати більше.