Ошибки тихого диска и надежность подкачки Linux

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

$ ls | compress_spaces.sh       # converts multiple spaces to one
$ ls | compress_spaces.sh TAB   # converts multiple spaces to a single tab character
$ ls | compress_spaces.sh TEST  # converts multiple spaces to the phrase TEST
$ compress_spaces.sh help       # show the help for this command

compress_spaces.sh

function show_help()
{
  IT=$(CAT <<EOF

  usage: {REPLACE_WITH}

  NOTE: If you pass in TAB, then multiple spaces are replaced with a TAB character

  no args -> multiple spaces replaced with a single space
  TAB     -> multiple spaces replaced with a single tab character
  TEST    -> multiple spaces replaced with the phrase "TEST"

  )
  echo "$IT"
  exit
}

if [ "$1" == "help" ]
then
  show_help
fi

# Show help if we're not getting data from stdin
if [ -t 0 ]; then
  show_help
fi

REPLACE_WITH=${1:-' '}

if [ "$REPLACE_WITH" == "tab" ]
then
  REPLACE_WITH=$'\t'
fi
if [ "$REPLACE_WITH" == "TAB" ]
then
  REPLACE_WITH=$'\t'
fi

sed "s/ \{1,\}/$REPLACE_WITH/gp"
12
11.03.2016, 19:10
3 ответа

Я не думаю, что существует "канонический" путь, поэтому следующее мое личное мнение.

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

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

Напротив, ZFS прочная и зрелая (ИМХО). Итак, чтобы ответить на ваш вопрос, я бы использовал ZFS (кстати, он не потребляет много памяти - см. Ниже).

Но для вас btrfs может быть правильным выбором, поскольку вы уже используете его (если я правильно понял), и в одном из комментариев выше показано, как использовать его для обмена.

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

Потребление памяти ZFS

Существует распространенное заблуждение относительно потребления памяти ZFS. ZFS обычно не потребляет много памяти; Фактически, он работает с ТБ хранилища на машинах с 2 ГБ ОЗУ. Только если вы используете дедупликацию (по умолчанию отключена), тогда потребуется много-много оперативной памяти.

Аппаратное обнаружение / исправление ошибок

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

Ну, не во всех случаях или неожиданно реагируют на ошибки. В качестве примера возьмем типичную конфигурацию RAID5. Обычно, если на одном диске есть проблема, он сообщает об этом в RAID, который, в свою очередь, создает данные для чтения с других дисков и передает их, но также записывает их обратно на неисправный диск (который, в свою очередь, вероятно, переназначает сектор перед записью данных); если один и тот же диск сообщает о слишком большом количестве ошибок, RAID переводит его в автономный режим и сообщает об этом администратору (если он настроен правильно).

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

Это разумное поведение? Насколько мне известно, большинство аппаратных контроллеров RAID5 и даже md RAID Linux работают именно так.

Я не знаю, как исправить ошибки в btrfs, но со временем вам следует внимательно прочитать документацию еще раз, особенно если вы используете RAID-массив btrfs.

Тихая гниль долота

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

То, что это происходит, не является моим личным мнением: по крайней мере, Google, Amazon и CERN опубликовали подробные официальные документы, охватывающие именно эту тему. Документы общедоступны для бесплатного скачивания. Они проводили систематические эксперименты с несколькими миллионами жестких дисков и сотнями тысяч серверов / запоминающих устройств либо потому, что у них были проблемы с необнаруженным повреждением данных, либо потому, что они хотели знать, что делать, чтобы предотвратить это, прежде чем это произойдет.

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

Таким образом, тихая гниль битов, т. Е. Необнаруженное повреждение данных в любой точке пути передачи,это проблема реальной жизни.

Время жизни данных

Уоррен Янг прав, когда говорит, что данные подкачки имеют короткое время жизни. Но я хотел бы добавить следующее соображение: в подкачку попадают не только данные (в смысле документов), но (возможно, даже более вероятно) части операционной системы или другого работающего программного обеспечения. . Если бы у меня был MP3 в свопинге, я мог бы жить с небольшим переворачиванием. Если (из-за чрезвычайной ситуации) части моего производственного программного обеспечения httpd-сервера находятся в режиме подкачки, я ни в коем случае не могу жить с перевернутым битом, который позже приведет к выполнению поврежденного кода, если он не обнаружен.

Эпилог

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

Сказав это, учтите, что вы никогда не получите абсолютной безопасности. Лично я доверяю своей ECC RAM больше, чем своим дискам, и я убежден, что ZFS с ее сквозными контрольными суммами снижает вероятность проблем на порядки. Однако я бы никогда не рекомендовал использовать ZFS без ECC RAM.

Отказ от ответственности: я никоим образом не связан с каким-либо поставщиком или разработчиком ZFS. Это верно для всех вариантов (вилок) ZFS. Я просто стал его поклонником в последние дни ...

0
27.01.2020, 19:56

Swap has ??? <--- this is my question

Подкачка по-прежнему не защищена в Linux (, но см. UPD ).

Ну, конечно, в Linux есть ZFS, которая может быть хранилищем подкачки , но при некоторых обстоятельствах все еще существует блокировка -вверх , что фактически отменяет эту возможность.

Btrfs по-прежнему не может обрабатывать файлы подкачки . Они упоминают о возможном использовании обратной связи, хотя отмечают, что она имеет плохую производительность. Есть неясное указание на то, что в Linux 5 это наконец может быть (? )…

Патчи для защиты обычного свопа с контрольными суммами не стали массовыми.

Итак, все -в -все :нет. У Linux все еще есть пробел.

УПД.:Как указывает @ sourcejedi, существует такой инструмент, как dm -целостность. Ядро Linux, начиная с версии 4.12, получило цель устройства отображения -, которую можно использовать для предоставления контрольных сумм для любых общих блочных устройств, и те, которые предназначены для подкачки, не являются исключением. Инструментарий широко не включен в основные дистрибутивы, и большинство из них не имеют никакой поддержки в системе udev sub -, но со временем это должно измениться. В сочетании с поставщиком избыточности, скажем, установленным поверх MD, также известного как Linux Software RAID, должна быть возможность не только обнаруживать битовую гниль, но и перенаправлять -запрос ввода-вывода на исправные данные, поскольку целостность dm -будет означать, что есть проблема, и MD должен справиться с ней.

2
27.01.2020, 19:56

дм -целостность

См.:Документация/устройство -mapper/dm -целостность.txt

dm-integrityобычно используется в режиме ведения журнала. В случае обмена можно было бы обойтись без ведения журнала. Это может значительно снизить нагрузку на производительность. Я не уверен, нужно ли вам переформатировать раздел целостности подкачки -поверх -при каждой загрузке, чтобы избежать ошибок после нечистого завершения работы.

В первоначальном объявлении dm-integrityавтор вместо этого отдает предпочтение «защите целостности данных на более высоком уровне». В случае подкачки это открыло бы возможность хранения контрольных сумм в ОЗУ. Однако этот вариант потребует нетривиальных -модификаций текущего кода подкачки и увеличения использования памяти. (Текущий код эффективно отслеживает подкачку, используя экстенты, а не отдельные страницы/секторы ).


ДИФ/ДИКС?

Поддержка DIX была добавлена ​​Oracle в Linux 2.6.27(2008 ).

Обеспечивает ли использование DIX целостность от конца -до -конца?

Вы можете проконсультироваться со своим поставщиком. Я не знаю, как вы можете сказать, если они лгут об этом.

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

DIF сам по себе увеличивает защиту данных при передаче между HBA и запоминающим устройством . (См. также:презентацию с некоторыми цифрами о разнице в частотах ошибок).

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

  • DIF/DIX are orthogonal to logical block checksums
    • We still love you, btrfs!
    • Logical block checksum errors are used for detection of corrupted data
    • Detection happens at READ time
    • ... which could be months later, original buffer is lost
    • Any redundant copies may also be bad if original buffer was garbled
  • DIF/DIX are about proactively preventing corruption
    • Preventing bad data from being stored on disk in the first place
    • ... and finding out about problems before the original buffer is erased from memory

-- lpc08-data-integrity.pdf from oss.oracle.com

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

Полная лживость относительно маловероятна в «корпоративных» контекстах, где в настоящее время используется DIX; люди бы это заметили. Кроме того, DIF был основан на существующем оборудовании, которое можно было отформатировать с секторами по 520 -байт. Протокол использования DIF якобы требует, чтобы вы сначала переформатировали диск, см., например. команду sg_format.

Что более вероятно, так это реализация, которая не следует истинному принципу end -to -end . В качестве одного примера упоминается поставщик, который поддерживает более слабую контрольную сумму для DIX для экономии циклов ЦП, которая затем заменяется более сильной контрольной суммой ниже в стеке. Это полезно, но это не полная защита от конца -до -.

В качестве альтернативы ОС может генерировать собственные контрольные суммы и сохранять их в пространстве тегов приложения. Однако это не поддерживается в текущей версии Linux (v4.20). Комментарий, написанный в 2014 году, предполагает, что это может быть связано с тем, что «очень немногие устройства хранения действительно позволяют использовать пространство тегов приложения». (Я не уверен, относится ли это к самому устройству хранения, HBA или к тому и другому ).

Какие устройства DIX доступны для работы с Linux?

The separation of the data and integrity metadata buffers as well as the choice in checksums is referred to as the Data Integrity Extensions [DIX]. As these extensions are outside the scope of the protocol bodies (T10, T13), Oracle and its partners are trying to standardize them within the Storage Networking Industry Association.

-- v4.20/Documentation/block/data-integrity.txt

Википедия сообщает мне, что DIF стандартизирован в NVMe 1.2.1. Для HBA-адаптеров SCSI кажется немного сложным определить это, если у нас нет стандарта, на который можно было бы указать. На данный момент правильнее было бы говорить о поддержке «Linux DIX» :-). Есть доступные устройства:

SCSI T10 DIF/DIX [sic] is fully supported in Red Hat Enterprise Linux 7.4, provided that the hardware vendor has qualified it and provides full support for the particular HBA and storage array configuration. DIF/DIX is not supported on other configurations, it is not supported for use on the boot device, and it is not supported on virtualized guests.

At the current time, the following vendors are known to provide this support...

-- RHEL 7.5 Release Notes, Chapter 16. Storage

Все оборудование, упомянутое в примечаниях к выпуску RHEL 7.5, является Fibre Channel.

Я не знаю этот рынок. Похоже, что в будущем DIX может стать более широко доступным на серверах. Я не знаю причин, по которым он стал бы доступен для потребительских дисков SATA -, насколько мне известно, нет даже фактического стандарта -для формата команд. Мне будет интересно посмотреть, станет ли он более широко доступен на NVMe.

3
27.01.2020, 19:56

Теги

Похожие вопросы