Опыт эксплуатации Mint 18 на btrfs в raid1 конфигурации (положительно, но есть нюансы)

О том о сем
В сети
Аватара пользователя

Автор темы
slant
Сообщения: 1161
Зарегистрирован: 21 июн 2017, 15:09
Решено: 16
Благодарил (а): 7 раз
Поблагодарили: 426 раз

Опыт эксплуатации Mint 18 на btrfs в raid1 конфигурации (положительно, но есть нюансы)

Сообщение slant » 25 окт 2017, 00:03

Итак, это будет просто нечто вроде отчета об опыте использования. Для общей информации. Думаю, будет полезно тем, раздумывает - "надо оно мне, или не очень?".

Система у меня была установлена первоначально на один винт 640гб самсунг 9-ти летней давности. Причем смарт еще до установки уже намекал, что винту пора на пенсию. Однако, на момент установки свободным был только он а решение о полном переходе еще не принято. Для эксперимента, как я посчитал - вполне нормально.
Итого, туда был поставлен Минт 18.1 на btrfs в качестве единственной и основной файловой системы. Диск был разбит на два раздела - для данных и для swap. В общем-то установка в конфигурации по умолчанию. Тут еще надо отметить, что при установке на btrfs установщик сам создает два подраздела - @, @home. В первый ставится /, второй используется под home соответственно. Преимущество такой конфигурации - свободное место они делят между собой по мере надобности.

Система вполне себе хорошо стала, оказалась обжита и быстро перешла в разряд основной. Встал вопрос о том, что держать ее на ненадежном диске уже становится черевато. К тому времени она оказалась проапгрейжена до 18.2 а ядро вообще установлено из ветки 4.10. Частично из-за KVM, частично как раз из-за btrfs. Она и в 4.4 уже имеет статус стабильной не говоря уже об 4.8, но в 4.10 кое-что оптимизировали и еще улучшили в ее работе если верить патчноутам. Хотелось иметь посвежее. В общем - стал вопрос о том, что надо либо менять диск, либо делать raid1. А лучше и то, и другое. :)

Менять диск было слегка не на что, а вот выделить второй - вполне. Это был тоже самсунг, только посвежее, и 1ТБ объемом. На нем тоже было сделано 2 раздела свап и пустой - под будущее зеркало. Далее этот раздел был добавлен к первому диску, изменен тип хранения данных, метаданных, и sys на raid1 и сделан ребаланс. (В отличии от обычного софтрейда, добавить диск мало - нужно еще вручную сконфигурировать как именно хочется его использовать. Но зато это легко делается динамически, причем на смонтированном разделе). Разный размер дисков тут совершенно не препятствие. Более того raid1 здесь работает несколько не так, как с mdadm. Напрмер - можно собрать массив из 3-ех дисков размером в 1тб каждый, и суммарный объем массива получится 1.5Тб. Т.е. использоваться будет все наличное пространство. А можно собрать и набор из одного 2ТБ и 2х 1Т дисков. И получить 2ТБ зеркало в сумме. И это все еще будет именно raid1.

В общем - эта конфигурация проработала без малейших нареканий, пока первый диск не решил, что он на этом свете и так чересчур зажился а потому - пора и честь знать. И сдох. Тут проявился мой первый косяк - я забыл проинсталировать grub на второй диск массива. И потерял возможность загрузки.

Казалось бы - что тут такого - грузи live да восстанавливай. А вот не тут-то было. Здесь вылез мой второй косяк. И некторая особенность btrfs при работе с RAID1. Во первых - загрузится с разрушеным массивом так просто вы не сможете. Потому что массив окажется в режиме RO, либо система вообще не сможет смонтировать массив (нужна опция degraded). Кстати, пока он в этом режиме - второй диск к нему добавить тоже не получится. Он же RO - значит никаких изменений. Вообще. Чтобы включить запись в состоянии degraded - нужно монтировать с соответствующей опцией. Т.е. менять fstab. А не получится. Т.к. RO. Т.е. нужно в любом случае загрузится с live, и там уже примонтировать вручную. А вот здесь всплывает второй подводный камень, на который я и налетел с размаху. Итак: У ВАС РОВНО ОДНА ПОПЫТКА ЗАПУСКА МАССИВА В РЕЖИМЕ DEGRADED C ВОЗМОЖНОСТЬЮ ЗАПИСИ. Если в отмонтируете раздел, который был смонтирован с возможностью записи не добавив второй диск - больше вы его смонтировать в режиме rw не сможете. А значит - не сможете и добавить новый диск, т.к. эта операция выполняется ТОЛЬКО на смонтированном разделе, причем смонтирован он должен быть в режиме RW. Вот такие забавные пироги. А я лично обнаружил этот нюанс когда вместо добавления нового диска, попытался восстановить загрузчик и перегрузился потом... :)

В прочем, не все так страшно. Во первых - все это делается для того, чтобы не в коем случае не потерять данные. Т.е. если не пытаться делать что-то непотребное - потерять данные риска нет. Вообще. Они всегда доступны для чтения. Даже если диск уже ушел в вечное RO. Так что - ставим новый диск, переносим содержимое на него через rsync, пересоздаем раздел который ушел в вечное RO и добавляем его обратно. Дольше, зато надежно. Во вторых - есть неофициальный патч ядра, для того чтобы можно было смонтировать degraded раздел более одного раза. Но теоретически он может вызвать частичную потерю данных при регулярной работе - потому не стоит такое ядро использовать постоянно. Кроме того - авторы сами считают такую особенность не самой лучше стороной FS и собираются это дело поменять (нельзя сказать исправить, т.к. не ошибка, а так оно и должно работать в рамках ее текущей логики - упор в разработке делался на сохранность данных.)

Итого: Я гонял систему на btrfs весьма интенсивно, сначала в single потом raid1. Бывали проблемы с питанием - машина вырубалась совершенно внезапно. Живем наблюдал умирание диска, сыпалась поверхность, так что понаблюдал как btrfs с этим справляется. И надо сказать - очень неплохо. Когда сыпется диск в классическом soft-raid часто это вызывает дикие тормоза. Даже завершить работу системы корректно уже бывает проблемой. На btrfs - заметно, но система остается вполне рабочей. За все это время FS не дала ни единого повода переживать за сохранность данных. Да, есть объективные неудобства, в случае выхода одного диска из строя. Но и только. С основной задачей (сохранность данных) она справляется не хуже классического софт-рейда. Убедился лично. А вот гибкость у такого варианта по сравнению с классическим софт-рейдом значительно выше.

В сети
Аватара пользователя

Автор темы
slant
Сообщения: 1161
Зарегистрирован: 21 июн 2017, 15:09
Решено: 16
Благодарил (а): 7 раз
Поблагодарили: 426 раз

Опыт эксплуатации Mint 18 на btrfs в raid1 конфигурации (положительно, но есть нюансы)

Сообщение slant » 23 дек 2017, 11:08

Нарисовалось продолжение истории.

Есть у меня "тестовый стенд" машинка предыдущего поколения, но еще вполне себе. Я на ней кроме всего прочего тестирую всякое разное, из того, что в вируталке не сделать, или оно там будет давать искаженную картину. К ней у меня прилагается несколько старых сменных винчестеров с разными системами. Так вот... Включаю я этот стенд как-то утром - а машина не грузится. Смотрю протокол загрузки... ёрш его так - куча ошибок диска. Ну все, думаю - крышка очередному самсунгу. (На этом винте - минт 18 на btrfs). Вчитываюсь внимательнее - и вижу в логе нечто не совсем привычное: ругань на CRC. Начинаю разбираться и вижу дивную картину. Ругается именно драйвер btrfs - данные мол повреждены, контрольная сумма не сходится. Причем как при чтении, так и при записи.
Все, думаю. Готов винт - посыпался.

Достаю другой винт, (там был mint 17 на ext4), ставлю в машину... Система не грузится. На сей раз молча - просто зависает на одной из рядовых операций в процессе. Спустя какое-то время вылетает сообщение о проблеме IO. Перегружаю машину - та же картина,только перед этим еще и восстановление раздела запустилось. Третий раз машина просто вылетела с ошибкой на этапе попытки смонтировать root.

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

Так вот, возвращаясь к нашим дискам. Там где была ext4 - файловая система оказалась разрушена практически полностью. Благо ничего ценного там не было. А вот диск где система была на btrfs - не пострадал вообще. После замены кабеля машина загрузилась как ни в чем не бывало. Сами понимаете, старый десктоп, никакой ECC памяти там не было. Тем не менее - свойство btrfs писать контрольные суммы и COW как основной метод записи надежно защитили данные от глючного кабеля, который гнал ошибки по шине данных. Такие дела.

Не призываю срочно всех переходить на эту систему - есть области где она объективно не продходит, но популярное в некоторых кругах мнение, что для нее нужно только идеально работающее железо и ECC память - явно ошибочно. Скорее наоборот - в таких условиях как случились у меня, на проблемном железе, она оказалась надежнее чем ext4.

P.S. Винт с btrfs тоже перегружался несколько раз еще вися на глючном кабеле - и побольше чем тот, что был с ext4. Так что - явно не однократное везение.

В сети
Аватара пользователя

Chocobo
Сообщения: 8701
Зарегистрирован: 27 авг 2016, 19:57
Решено: 189
Откуда: НН
Благодарил (а): 588 раз
Поблагодарили: 2377 раз

Опыт эксплуатации Mint 18 на btrfs в raid1 конфигурации (положительно, но есть нюансы)

Сообщение Chocobo » 23 дек 2017, 11:26

ЧуднЫе дела.
Странным видится то, что по сути корневая фс сначала же должна же грузится в ro
Или в апстарте 17-го минта не было подобных ремаунтов инитом?
Изображение
   
Изображение

В сети
Аватара пользователя

Автор темы
slant
Сообщения: 1161
Зарегистрирован: 21 июн 2017, 15:09
Решено: 16
Благодарил (а): 7 раз
Поблагодарили: 426 раз

Опыт эксплуатации Mint 18 на btrfs в raid1 конфигурации (положительно, но есть нюансы)

Сообщение slant » 23 дек 2017, 11:40

Грузится как я помню в RO только образ initramfs. А настоящий корень сразу монтируется в RW. Точнее - это уже этап монтирования по конфигурации из /etc/fstab. Речь была о нем.
А, еще для справки, чтобы странным не казалось: на том диске с 17-ым минтом boot был отдельным разделом.

В сети
Аватара пользователя

Chocobo
Сообщения: 8701
Зарегистрирован: 27 авг 2016, 19:57
Решено: 189
Откуда: НН
Благодарил (а): 588 раз
Поблагодарили: 2377 раз

Опыт эксплуатации Mint 18 на btrfs в raid1 конфигурации (положительно, но есть нюансы)

Сообщение Chocobo » 23 дек 2017, 12:26

Про инитрд понятно, но оно и не особо к дисковым фс относится после вычитки)
ну, и как бы в любом дмесдж увидим
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.0-104-generic root=UUID=9438bf02-79c2-41f4-86ed-a7459a1a21ba ro quiet
[ 3.593292] EXT4-fs (sdb2): re-mounted. Opts: errors=remount-ro
(sdb2 тут дейстивтельно мой корень)
Я все это к тому, что может не фс тебя спасла :) попробуй провернуть финт на ext4 с 18-ми минтами если "особенный" сигнальный кабель еще под рукой
Изображение
   
Изображение

В сети
Аватара пользователя

Автор темы
slant
Сообщения: 1161
Зарегистрирован: 21 июн 2017, 15:09
Решено: 16
Благодарил (а): 7 раз
Поблагодарили: 426 раз

Опыт эксплуатации Mint 18 на btrfs в raid1 конфигурации (положительно, но есть нюансы)

Сообщение slant » 23 дек 2017, 14:04

У btrfs не используется опция remount-ro, а у 17-го минта на ext4 наоборот - по умолчанию.

Вот только эта опция - не влияет на искаженные данные. Она поможет, если у диска идут настоящие bed секторы, и информация о соответствующих ошибках по каналу данных. А этот кабель вызывал исключительно ошибки в самих данных. Возможно она и срабатывала, т.к. у дисков я потом увидел изменения в параметрах смарт 199 (UDMA_CRC_Error_Count - собственно, основной симптом для проверки кабеля, при отсутствии изменения 5 и 196 ), и 202 (Data_Address_Mark_Errs), но видимо, слишком поздно оно уходило в RO. Если вообще уходило.

В сети
Аватара пользователя

Автор темы
slant
Сообщения: 1161
Зарегистрирован: 21 июн 2017, 15:09
Решено: 16
Благодарил (а): 7 раз
Поблагодарили: 426 раз

Опыт эксплуатации Mint 18 на btrfs в raid1 конфигурации (положительно, но есть нюансы)

Сообщение slant » 28 апр 2018, 01:54

Нашел интересный фактик про btrfs.
После наложения патчей от недавно нашумевших дырок в процессорах, эта FS оказывается меньше всего страдает от потери производительности. В некоторых сценариях - почти вообще не страдает. А вот XFS наоборот - в некоторых случаях теряет до 30-40% своей скорости.
Дровишки отсюда: https://www.phoronix.com/scan.php?page= ... 5-fs&num=2

P.S. Обращаю внимание, что данная FS все равно лидером по скорости не является в любом случае. Но сам факт занятный. Тем более, что с включенными патчами безопасности в ядрах, XFS в некоторых тестах проседает практически до ее уровня.

Вернуться в «Болталка: Оффтоп, разбор полетов»