Мовчазні помилки диска та надійність підкачки Linux

Я розумію, що жорсткі диски та SSD-диски реалізують основні виправлення помилок всередині накопичувача, і більшість конфігурацій RAID, наприклад mdadm, буде залежати від цього, щоб вирішити, коли диск не виправить помилку і його потрібно вимкнути в автономному режимі. Однак це залежить від того, що сховище є на 100% точним у своїй діагностиці помилок. Це не так, і загальна конфігурація, як дзеркало RAID-1 з двома приводами, буде вразливою: припустимо, деякі біти на одному накопичувачі мовчки пошкоджені, а привід не повідомляє про помилку читання. Таким чином, файлові системи, такі як btrfs та ZFS, реалізують власні контрольні суми, щоб не довіряти грандіозним мікропрограмним накопичувачам, глянцевим SATA-кабелям тощо.

Так само оперативна пам'ять може також мати проблеми з надійністю, і, таким чином, у нас є ECC RAM для вирішення цієї проблеми.

Моє запитання таке : що є канонічним способом захисту файлу swap Linux від тихої корупції / бітової гнилі, не зафіксованої прошивкою диска на конфігурації двох дисків (тобто за допомогою драйверів основного ядра)? Мені здається, що конфігурація, якій тут не вистачає захисту від кінця до кінця (наприклад, такої, яку надає btrfs), дещо заперечує спокій, внесений оперативною пам’яттю ECC. Але я не можу придумати гарний спосіб:

• btrfs взагалі не підтримує свопфіли. Ви можете налаштувати циклічний пристрій з файлу btrfs і зробити своп на цьому. Але в цьому є проблеми:
  • Випадкові записи не працюють добре: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
  • Пропозиція відключити копіювання під час запису також відключить контрольну суму - тим самим переможивши всю точку цієї вправи. Їх припущення полягає в тому, що файл даних має свій внутрішній захист.
• ZFS в Linux дозволяє використовувати ZVOL як своп, що, напевно, може спрацювати: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap - однак, з мого читання, ZFS, як правило, вимагає пам’яті, і змушує його працювати в свопі. -тільки додаток звучить як деякий твір, що з'ясовує це. Я думаю, що це не мій перший вибір. Чому вам доведеться використовувати якийсь модуль ядра поза деревом просто для того, щоб мати надійний своп поза мною - безумовно, є спосіб досягти цього з найсучаснішими дистрибутивами / ядрами Linux в цей день і вік?
• В списку розсилки ядра Linux з патчами насправді була нитка для включення контрольних сум у самому диспетчері пам'яті, саме з тих причин, які я обговорюю в цьому питанні: http://thread.gmane.org/gmane.linux.kernel/989246 - на жаль, наскільки я можу сказати, патч загинув і ніколи не ввійшов до нього за течією з незрозумілих мені причин. Шкода, це звучало як приємна особливість. З іншого боку, якщо ви помістите своп на RAID-1 - якщо пошкодження виходить за рамки можливості контрольної суми для відновлення, ви хочете, щоб менеджер пам'яті спробував прочитати з іншого диска, перш ніж панікувати або що завгодно, що є ймовірно, виходить за рамки того, що повинен робити менеджер пам'яті.

Підсумовуючи:

• ОЗУ має ECC для виправлення помилок
• Файли на постійному сховищі мають btrfs для виправлення помилок
• Зміна має ??? <--- це моє питання

Ми довіряємо цілісність даних, отриманих за допомогою swap, оскільки обладнання для зберігання даних має контрольні суми, CRC тощо.

В одному з коментарів вище, ви говорите:

правда, але це не захистить від бітових переворотів поза самим диском

"Це" означає контрольні сум диска тут.

Це правда, але SATA використовує 32-бітні CRC для команд та даних. Таким чином, у вас є 1 на 4 мільярди шансів непомітно зіпсувати дані між диском та контролером SATA. Це означає, що безперервне джерело помилок може вводити помилку так часто, як кожні 125 переданих МіБ, але рідкісне, випадкове джерело помилок, наприклад, космічні промені, спричинило б невизначені помилки із зникаючою невеликою швидкістю.

Зрозумійте також, що якщо у вас є джерело, яке викликає невиявлену помилку зі швидкістю десь біля одного на 125 передаваних МіБ, продуктивність буде жахливою через велику кількість виявлених помилок, які потребують повторної передачі. Моніторинг та реєстрація даних, ймовірно, вчасно попередить вас про проблему, щоб уникнути непомітної корупції.

Що стосується контрольних сум носія накопичувача, кожен диск SATA (а перед ним PATA) використовує певні галузеві контрольні суми. Однією з характерних особливостей жорстких дисків "корпоративних" є більші сектори, захищені додатковими функціями цілісності даних , що значно знижує ймовірність виявлення помилки.

Без таких заходів не було б сенсу в резервному секторі на кожному жорсткому диску: сам накопичувач не міг би виявити поганий сектор, тому він ніколи не міг би поміняти свіжі сектори в.

В іншому коментарі ви запитуєте:

якщо SATA є таким надійним, чому існують контрольні суми файлових систем на зразок ZFS, btrfs, ReFS?

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

На додаток до цього, час з часом, як правило, скорочується, що залежить від збільшення частоти ядра та libcоновлень, віртуалізації, хмарних архітектур тощо.

Крім того, більшість даних в свопі по суті використовуються в добре керованій системі, тому що вона не вичерпується основної оперативної пам'яті. У такій системі єдині речі, які закінчуються свопом - це сторінки, які програма не використовує часто, якщо ніколи. Це частіше, ніж можна здогадатися. Більшість динамічних бібліотек, на які посилаються ваші програми, мають в собі підпрограми, які ваша програма не використовує, але їх потрібно було завантажувати в оперативну пам'ять динамічним лінкером . Коли ОС бачить, що ви не використовуєте весь текст програми в бібліотеці, він заміняє його, звільняючи місце для коду та даних, якими користуються ваші програми . Якщо такі розміщені сторінки пам'яті пошкоджені, хто б коли-небудь знав?

Порівнюйте це з подібними ZFS, де ми очікуємо, що дані будуть довговічно та стійко зберігатися, щоб вони тривали не тільки поза поточним режимом роботи системи, але й поза терміном служби окремих пристроїв зберігання даних, що складаються із системи зберігання даних. ZFS і подібні вирішують задачу в масштабі часу приблизно на два порядки довше, ніж проблема, що вирішується свопом. Таким чином, у нас набагато вищі вимоги щодо виявлення корупції для ZFS, ніж для обміну Linux.

ZFS і подібні тут відрізняються від swap іншим ключовим способом: ми не обмінюємо файлові системи RAID разом. Коли на одній машині використовується кілька пристроїв для заміни , це схема JBOD , не така, як RAID-0 або вище. (наприклад, схема ланцюгових файлів заміни файлів macOS , Linux та swaponін.) Оскільки пристрої підкачки незалежні, а не взаємозалежні, як у RAID, нам не потрібна велика контрольна сума, тому що для заміни пристрою заміни не потрібно переглядати інші взаємозалежні пристрої заміни для дані, які повинні надходити на пристрої заміни. Згідно з умовами ZFS, ми не перепродаємо заміну пристроїв із зайвих копій на інших пристроях зберігання даних.

Все це означає, що ви повинні використовувати надійний замінний пристрій. Я колись використовував зовнішній корпус USB HDD на суму 20 доларів, щоб врятувати хворий пул ZFS, лише щоб виявити, що корпус сам по собі був ненадійним, вводячи власні помилки в процес. Сильна контрольна сума ZFS врятувала мене тут. Ви не можете уникнути такої кавалерської обробки носіїв пам’яті за допомогою файлу своп. Якщо пристрій swap вмирає, і, таким чином, наближається до найгіршого випадку, коли він може вводити невідкриту помилку кожні 125 переданих MiB, вам просто доведеться замінити його, якнайшвидше.

Загальне відчуття параної в цьому питанні переходить до примірника проблеми візантійських полководців . Прочитайте про це, обміркуйте дату 1982 року в науковому документі, що описує проблему у світі інформатики, а потім вирішіть, чи у 2019 році у вас є нові думки, щоб додати цю проблему. А якщо ні, то, можливо, ви просто використаєте технологію, розроблену трьома десятиліттями випускників КС, які всі знають про проблему візантійських генералів.

Це добре протоптана земля. Напевно, ви не можете придумати ідеї, заперечення чи рішення, про які вже не йшлося про смерть у журналах інформатики.

SATA, безумовно, не є надто надійним, але якщо ви не збираєтесь приєднатися до академічних закладів чи до однієї з команд з розробки ядра, ви не зможете істотно додати тут сучасний стан. Ці проблеми вже добре поєднуються, як ви вже відзначали: ZFS, btrfs, ReFS ... Як користувач ОС, ви просто повинні довіряти, що творці ОС переймаються цими проблемами для вас, оскільки вони також знають про візантійських генералів.

В даний час не практично розміщувати свій файл swap поверх ZFS або Btrfs, але якщо вищезгадане не заспокоїть вас, ви можете принаймні поставити його на xfs або ext4. Це було б краще, ніж використовувати спеціальний розділ swap.

dm-цілісність

Див.: Документація / пристрій-картограф / dm-integ.t.txt

dm-integrityзазвичай використовується в режимі журналу. У разі заміни, ви могли б домовитись обходитися без оформлення журналів. Це може значно знизити ефективність роботи. Я не впевнений, чи потрібно вам переформатувати розділ swap-over-integrite на кожному завантажувальному пристрої, щоб уникнути помилок після нечистого відключення.

У первинному оголошенніdm-integrity автор замість цього віддає перевагу "захисту цілісності даних на вищому рівні". У разі swap це відкрило б можливість зберігання контрольних сум в оперативній пам'яті. Однак ця опція вимагає нетривіальних модифікацій поточного коду swap, а також збільшення обсягу використання пам'яті. (Поточний код ефективно відстежує своп, використовуючи розширення, а не окремі сторінки / сектори).

DIF / DIX?

Підтримку DIX додала Oracle у Linux 2.6.27 (2008).

Чи забезпечує використання DIX цілісність цілісності?

Ви можете проконсультуватися з продавцем. Я не знаю, як ви могли сказати, чи брешуть вони про це.

DIX необхідний для захисту даних під час польоту між ОС (операційною системою) та HBA .

DIF сам по собі підвищує захист даних під час польоту між HBA та пристроєм зберігання даних . (Див. Також: презентація з деякими цифрами про різницю в показниках помилок ).

Саме тому , що контрольна сума в поле захисного стандартизована, технічно можливо реалізувати команди Dix без надання будь - яких захистів даних в стані спокою. Просто запропонуйте HBA (або запам'ятовуючий пристрій) відновити контрольну суму під час читання. Цей світогляд був чітко зрозумілий оригінальним проектом DIX.

• DIF / DIX є ортогональними для контрольних сум логічних блоків
  • Ми все ще любимо вас, btrfs!
  • Помилки контрольної суми логічного блоку використовуються для виявлення пошкоджених даних
  • Виявлення відбувається в ЧИТАТИ час
  • ... що може бути через кілька місяців, початковий буфер втрачається
  • Будь-які надлишкові копії також можуть бути поганими, якщо оригінал буфера був пошкоджений
• DIF / DIX - це проактивно запобігання корупції
  • У першу чергу запобігання збереженню поганих даних на диску
  • ... та дізнатися про проблеми, перш ніж початковий буфер буде стертий з пам'яті

- lpc08-data-integral.pdf від oss.oracle.com

В одній із їхніх ранніх публікацій про DIX згадується можливість використання DIX між ОС та HBA, навіть коли накопичувач не підтримує DIF.

Повна мінливість є малоймовірною у контекстах "підприємства", де зараз використовується DIX; люди це помітили б. Також DIF базувався на наявному апаратному забезпеченні, яке можна було відформатувати за допомогою 520-байтних секторів. Протокол використання DIF нібито вимагає спершу переформатувати диск, див. Наприклад sg_formatкоманду.

Імовірніше, що це реалізація, яка не відповідає справжньому принципу "кінець до кінця" . Для прикладу згадується постачальник, який підтримує слабший варіант контрольної суми для DIX для збереження циклів процесора, який потім замінюється більш сильною контрольною сумою далі в стеку. Це корисно, але це не повний захист від кінця до кінця.

Крім того, ОС може генерувати власні контрольні суми та зберігати їх у просторі тегів додатків. Однак для цього немає підтримки в поточному Linux (v4.20) . У коментарі, написаному в 2014 році, випливає, що це може бути тому, що "дуже мало пристроїв зберігання даних фактично дозволяють використовувати простір тегів додатків". (Я не впевнений, чи відноситься це до самого пристрою зберігання даних, HBA або обох).

Які типи DIX-пристроїв доступні для роботи з Linux?

Розмежування буферів метаданих даних та цілісності, а також вибір контрольних сум називається розширенням цілісності даних [DIX]. Оскільки ці розширення виходять за рамки органів протоколу (T10, T13), Oracle та його партнери намагаються стандартизувати їх у межах Асоціації мереж зберігання даних.

- v4.20 / Документація / блок / цілісність даних.txt

Вікіпедія каже мені, що DIF стандартизований у NVMe 1.2.1. Для HSI з SCSI здається, що це важко виправити, якщо у нас немає стандарту, на який слід звернути увагу. На даний момент, можливо, найточніше поговорити про підтримку "Linux DIX" :-). Доступні пристрої:

SCSI T10 DIF / DIX [sic] повністю підтримується в Red Hat Enterprise Linux 7.4, за умови, що постачальник апаратури кваліфікував це та забезпечує повну підтримку конкретної конфігурації HBA та масиву зберігання. DIF / DIX не підтримується в інших конфігураціях, він не підтримується для використання на завантажувальному пристрої та не підтримується у віртуалізованих гостей.

В даний час, як відомо, наступні постачальники надають цю підтримку ...

- Примітки до випуску RHEL 7.5, глава 16. Зберігання

Все обладнання, згадане в примітках до випуску RHEL 7.5, - це Fiber Channel.

Я не знаю цього ринку. Здається, DIX може стати більш доступним на серверах у майбутньому. Я не знаю жодної причини, чому вона стала б доступною для споживчих SATA-дисків - наскільки я знаю, немає навіть фактичного стандарту для формату команд. Мені буде цікаво дізнатися, чи стане вона доступна ширше в NVMe.

Зміна має ??? <--- це моє питання

Зміна все ще не захищена в Linux (але див. UPD).

Ну, звичайно, є Linux ZFS, який може бути сховищем своп, але все-таки є блокування за певних обставин - таким чином ефективно скасовуючи цю опцію.

Btrfs досі не може обробляти файли підкачки . Вони згадують про можливе використання циклічного зворотного зв'язку, хоча, як зазначається, мають низьку продуктивність. Існує неясна ознака того, що Linux 5 міг би його остаточно (?)…

Патчі для захисту звичайних своп самими контрольними сумами не дозволили йому перейти в мейнстрім.

Отже, все-все: ні. У Linux все ще є розрив.

UPD. : Як зазначає @ sourcejedi , існує такий інструмент, як dm-цілісність. Ядро Linux, починаючи з версії 4.12, отримало ціль пристрою-картографа, яку можна використовувати для надання контрольних сум на будь-які загальні блокові пристрої, і ті, які призначені для своп, не є винятком. Інструменти не вбудовані в основні дистрибутиви, і більшість з них не мають підтримки в підсистемі udev, але з часом це має змінитися. У поєднанні з провайдером надмірності, скажімо, поставте на верхню частину MD aka Linux Software RAID, слід не тільки виявити гниття бітів, але і перенаправити запит вводу / виводу до здорових даних, оскільки цілісність dm вказуватиме на наявність питання, і MD повинен це впоратися.

Я не думаю, що існує "канонічний" спосіб, тому наступне - моя особиста думка.

Здійснивши моніторинг просування btrfs з точки зору потенційного користувача, я мушу сказати, що це все ще мені якось незрозуміло. Є функції, які є зрілими і готовими до використання, і є функції, які, здавалося б, незрілі та небезпечні для використання.

Особисто я не маю часу вирішувати, яку функцію використовувати, а яку ні, відпускаю час, який мені знадобиться, щоб зрозуміти, як вимкнути або ввімкнути ці функції.

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

Але для вас btrfs може бути правильним вибором, оскільки ви його вже використовуєте (якщо я зрозумів, що ви праві), і один із коментарів, наведених вище, показує, як його використовувати для своп.

По чистому випадкові, я поміщав кілька серверів Linux на ZFS протягом останніх днів, щоразу включаючи кореневу файлову систему та своп. Перш ніж я це зробив, я дуже грунтовно провів деякі дослідження, які зайняли мене кілька днів. Короткий підсумок того, що я дізнався:

Споживання пам'яті ZFS

Існує поширене непорозуміння щодо споживання пам'яті ZFS. ZFS зазвичай не споживає багато пам’яті; насправді він працює з TB-накопичувачами на машинах з 2 ГБ оперативної пам’яті. Тільки якщо ви використовуєте дедупликацію (вимкнено за замовчуванням), тоді їй потрібно багато і багато оперативної пам’яті.

Виявлення / виправлення апаратних помилок

Чи є достатніми для встановлення цілісності даних SATA, PATA, RAID чи інші механізми виявлення / виправлення помилок - це тема, яка викликає нескінченні дискусії та навіть вогневі війни у ​​всіх місцях мережі. Теоретично апаратний запам'ятовуючий пристрій повинен повідомляти (і, можливо, виправляти) будь-яку помилку, з якою він стикається, а також апаратне забезпечення для передачі даних на всіх рівнях (чіпсет, пам'ять тощо).

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

Поки що так добре, але бувають випадки, коли несправні дані виходять з диска без диска, який повідомляє про помилку (див. Наступний розділ). Більшість RAID можуть виявити цю ситуацію, використовуючи інформацію про паритет, але їх реакція дурна: Замість повідомлення про помилку та зупинення передачі даних вони просто перерахують паритет на основі несправних даних і записують новий паритет у відповідний диск, таким чином позначаючи несправні дані як правильні назавжди.

Це розумна поведінка? Наскільки я знаю, більшість апаратних RAID5-контролерів і навіть md-RAID Linux працюють таким чином.

Я не знаю про виправлення помилок btrfs, але ви, зрештою, повинні ще раз уважно прочитати документи, особливо якщо ви використовуєте RAID btrfs.

Мовчазна гниль

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

Що це трапляється - це не моя особиста думка: принаймні Google, Amazon та CERN опублікували докладні довідки, що висвітлюють саме цю тему. Документи публічно доступні для завантаження безкоштовно. Вони проводили систематичні експерименти з декількома мільйонами жорстких дисків і сотнями тисяч серверів / пристроїв зберігання даних, або тому, що у них були проблеми з невиявленою корупцією даних, або тому, що вони хотіли знати, що робити, щоб запобігти цьому, перш ніж це сталося.

Підсумовуючи це, дані на їхніх фермах-серверах були зіпсовані зі швидкістю, значно вищою, ніж статистика MTBF, або інша теорія може очікувати. Під значно вищими, я маю на увазі порядки.

Тож мовчазна гниття бітів, тобто непомічена корупція даних у будь-якій точці шляху передачі, є реальною життєвою проблемою.

Термін служби даних

Воррен Янг прав, коли каже, що дані своп мають короткий термін експлуатації. Але я хотів би додати наступне враження: в обмін потрапляють не тільки дані (у сенсі документів), але (можливо, ще ймовірніше) частини O / S або іншого запущеного програмного забезпечення . Якщо у мене MP3 в свопі, я можу жити з гортаючим бітом. Якщо (через екстремальну ситуацію) частини мого виробничого сервера httpd-сервера знаходяться в свопі, я ні в якому разі не можу жити з гортаючим бітом, який згодом призводить до виконання пошкодженого коду, якщо його не виявлено.

Епілог

Для мене ZFS вирішує ці проблеми або, точніше, відсуває їх від дисків до пам'яті і тим самим зменшує ймовірність беззвучного гниття бітів на деякі порядки. Крім того, якщо правильно налаштовано (тобто дзеркала замість RAID), це забезпечує чітке та обґрунтоване виправлення помилок, яке працює як очікувалося і його можна зрозуміти зрештою.

Сказавши це, зауважте, що ви ніколи не отримаєте абсолютної безпеки. Особисто я більше довіряю оперативній пам’яті ECC більше, ніж своїм дискам, і я переконаний, що ZFS з її контрольними сумами знижує ймовірність проблеми на порядок. Я б ніколи не рекомендував використовувати ZFS без ECC RAM.

Відмова від відповідальності: я жодним чином не пов'язаний з будь-яким постачальником або розробником ZFS. Це справедливо для всіх варіантів (вилок) ZFS. Я просто став фанатом цього в минулі дні ...