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

Закрыто
Аватара пользователя

Автор темы
slant
Сообщения: 4504
Зарегистрирован: 21 июн 2017, 18:09
Решено: 99
Благодарил (а): 51 раз
Поблагодарили: 1992 раза
Контактная информация:

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

#1

25 окт 2017, 03: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
Сообщения: 4504
Зарегистрирован: 21 июн 2017, 18:09
Решено: 99
Благодарил (а): 51 раз
Поблагодарили: 1992 раза
Контактная информация:

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

#2

23 дек 2017, 14:08

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

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

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

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

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

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

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

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

Chocobo
Сообщения: 10015
Зарегистрирован: 27 авг 2016, 22:57
Решено: 215
Откуда: НН
Благодарил (а): 815 раз
Поблагодарили: 3010 раз
Контактная информация:

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

#3

23 дек 2017, 14:26

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

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

Автор темы
slant
Сообщения: 4504
Зарегистрирован: 21 июн 2017, 18:09
Решено: 99
Благодарил (а): 51 раз
Поблагодарили: 1992 раза
Контактная информация:

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

#4

23 дек 2017, 14:40

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

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

Chocobo
Сообщения: 10015
Зарегистрирован: 27 авг 2016, 22:57
Решено: 215
Откуда: НН
Благодарил (а): 815 раз
Поблагодарили: 3010 раз
Контактная информация:

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

#5

23 дек 2017, 15: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
Сообщения: 4504
Зарегистрирован: 21 июн 2017, 18:09
Решено: 99
Благодарил (а): 51 раз
Поблагодарили: 1992 раза
Контактная информация:

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

#6

23 дек 2017, 17:04

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

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

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

Автор темы
slant
Сообщения: 4504
Зарегистрирован: 21 июн 2017, 18:09
Решено: 99
Благодарил (а): 51 раз
Поблагодарили: 1992 раза
Контактная информация:

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

#7

28 апр 2018, 04:54

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

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

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

Автор темы
slant
Сообщения: 4504
Зарегистрирован: 21 июн 2017, 18:09
Решено: 99
Благодарил (а): 51 раз
Поблагодарили: 1992 раза
Контактная информация:

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

#8

23 янв 2019, 12:10

Подъехала очередная порция опыта.

На сей раз - на счет того, что эта система пережить не в состоянии.

Кому дальше читать лень: битую планку памяти она может не пережить. Однако это не моментальный процесс и все-таки не полностью фатальный (как у меня когда-то случилось с ext4 в аналогичной ситуации).

Грязные подробности: Стояла себе win10. На win10 стояла vmware workstation. В "варе" сидела виртуальная машина минт 19 с btrfs raid1, на двух физических винтах. Да, знаю что извращение, но так было нужно. :) Эксперименты проводились. :)

В один прекрасный момент винда начала падать в BSOD (с различными ошибками). Подозрение было на убитый винт хост-системы, т.к. у него возраст - "столько не живут". Однако проверки ничего не показали. Пропускаем несущественную часть диагностики, а выводы - подохла одна из планок памяти, причем так, что зацепило только "верхние" адреса, т.е. пока система запущена без нагрузки - все нормально. А вот когда общий объем занятого доходил до ~28 гиг - вот тогда то оно и вылазило. В результате всего этого система периодически умирала вместе с запущенной ВМ, а иногда та падала сама по себе. Творилось это непотребство больше двух недель, и в принципе все жило после очередной перезагрузки... но везение бесконечным не бывает.

Результат очередного особо фееричного падения: Полностью дохлая ntfs у хост системы, и слегка проблемная btrfs у ВМ. Все монтируется, структура и файлы на месте, но система не грузится в графический режим из-за нескольких недоступных файлов-библиотек от иксов и lightdm (как раз обновы ставились). В текстовой консоли - пожалуйста. В общем - прогноз по сохранности данных - высокий, прогноз по полному восстановлению без пересоздания FS заново - 50 на 50. btrfs scrub выдает одну ошибку которую не может исправить. Косяк, как я могу понять в метаданных, причем в обоих копиях - из за битой памяти в оной произошло закоррапчивание, которое и записалось потом. В общем-то к FS тут претензий нету, это походу сам драйвер дисков/контроллеров зацепило и его буфферы. Теоретически может еще помочь btrfs check --repair, но операция это из опасных, и на случай когда терять уже нечего. Потому сначала оттуда надо слить остатки экспериментов которые некоторую ценность представляют. Потом отпишусь на счет конечного результата.

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

Dja
Сообщения: 6875
Зарегистрирован: 27 авг 2016, 20:03
Решено: 30
Откуда: Voskresensk
Благодарил (а): 1312 раз
Поблагодарили: 724 раза
Контактная информация:

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

#9

23 янв 2019, 14:21

slant писал(а):
23 янв 2019, 12:10
когда общий объем занятого доходил до ~28 гиг
Это ж сколько там всего оперативы? :hm:

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

Автор темы
slant
Сообщения: 4504
Зарегистрирован: 21 июн 2017, 18:09
Решено: 99
Благодарил (а): 51 раз
Поблагодарили: 1992 раза
Контактная информация:

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

#10

23 янв 2019, 14:33

Дык 32 гига. Если учитывать что это платформа под виртуалки (и не только под одну запустить-посмотреть) - еще и не так уж много.

Закрыто

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

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 5 гостей