Заменяем диск в zfs raidz

[2gusia]

Эта запись встает на место одноименной записи от 2013 г. С тех пор много воды утекло, старую я не удаляю. Тем более, что настоящая запись - про замену диска в zfs массиве на именованных gpt разделах. А старая - про другие варианты

Comments

[vasileo_rus]

Благодарю Вас за подробную инструкцию, наверное скоро придется воспользоваться)))
Есть вопрос - в массиве работают два старых диска Seagate на 400Gb 7200 об/мин. Эти паразиты создают жуткую вибрацию и резонансы в корпусе, ночью просто невыносимо под это засыпать. Мне нечем заменить их и тратиться не хочется, можно ли как то уменьшить частоту вращения шпинделей?

[2gusia]

Она задана конструктивно - только физической заменой.
Но вы можете поиграться параметром AAM - аккустический менеджмент - он в дисках под гаечнвм ключом.

И можете поискать корзинку с демпферами виброгасящими

[ext_5525763]

Вот такие корзины стоят в nas у меня. Гасят отлично. Вариант без кулера. https://www.aliexpress.com/item/32892613361.html

[mikespb]

Запись годная, сохраню на всякий случай ))

заодно поделюсь буквально 3-х месячной давности сторей
массив raidz2-0 (собирал из бу хлама так что делал с запасом)
На каком то этапе начали на почту сваливатся варнинги то ошибка, то диск отвалился , то два... особо не придавал значения, на каком то этапе поменял все сата кабели, но так или иначе ошибки не прекращались...я грешил на все что можно, опуская все детали в итоге сервак сдох от слова соовсем...
Благо материнка была серверная с IPMI и логами и можно было востановить историю событий , в двух словах в течении года медлено сдыхал блок питания плавно просаживая 5-вольтную линию по каким-то там тысячным вольтам до полной невменяемости, сдох сам и утянул за собой материнку.
Вскрытие показало что конденсаторы не рванули по крестообразным насечкам как и должны были бы, а распухли развальцевались снизу и железная оболочка висела на них как колпачек.

[2gusia]

Странные медленно нарастающие проблемы - это очень часто БП. Я недавно заменил свой в десктопе. Взял Seasonic :) - себе же, что экономить на спичках.

Скорость хеширования

[silver_ra]

Добрый день, Михаил и читатели. Собрал NAS по Вашим инструкциям уже очень давно, процессор G2120 и массив RAID-5 на 6-ти 2TB дисках, собранном на контроллере Dell Perc H700. Как-то раз помер один диск, я этого даже не заметил, до перегрузки сервера. Вычислил умерший диск, заменил его и все работало дальше. Есть у меня один торрент, который я стараюсь держать в актуальном состоянии, библиотека либрусек, объем около 250GB. При его обновлении очень долго проверяются имеющиеся файлы, 1h40min. Казалось бы, ну и фиг с ним, подумаешь. Однако зачесалось. Захотелось улучшений. Поменял процессор на Xeon E3-1245V2, 4 ядра, 8 потоков, красота. Памяти к имеющимся 4ГБ добавил еще 8. Повторил проверку файлов - 50min. Ну вроде стало лучше, угомонись еще на неск лет, зуд успокоил вроде, но нет. Вижу, что первая половина этой раздачи проверяется на скорости 1GB в пару секунд примерно. Процессор утилизируется хорошо - по всем потокам нагрузка 6-8%. На второй половине скорость падает до 15 сек на 1GB примерно и загрузка процессора болтается около ноля.

Re: Скорость хеширования

[2gusia]

У zfs много плюсов, но ничто не идеально. Например, нет дефрагментации. А то, что она не нужна - правда лишь частично.

если качать торренты прямо в zfs массив без тюнига (а он состоит прежде всего в увеличении куска записи трансмишн) - то фрагментация и вылезет - вы ее и видите.

Я стандартно качаю на другой диск, а потом уже переношу на массив. Можно сделать это и средствами самого трансимишн.

По поводу борьбы в вашем случае. Идеально - сделать бекап, удалить все и восстановить. Будет много быстрее.

Как частичное, но неплохое решение, если места на массиве много (!!!) - скопируйте проблемные файлы в другую папку на том же датасете, потом удалите оригиналы.

[ext_5425285]

Добрый день!
Спасибо за блог и чтиво. У меня RAIDZ-1 на 3x SMR дисках от Seagate. Крутятся, правда, на Debian с ZFS, но проблем с отвалами совершенно нет. По мнению некоторых "экспертов", проблемы SMR дисков вылезают боком при их совмещении в массивах с CMR дисками.
Я недавно неудачно "проигрался" с дисками и случайно грохнул один из дисков в RAID-Z1 - убил раздел, попутав sdf и sdd (gpt метки как-то не работают в Linux). Проблема решилась также, с помощью zpool replace и ресильвер. Однако я столкнулся с тем, что Gpart в Линукс работает "не так" как в BSD. Удаление остатков ФС с убитого диска делал под виндой и сейчас на этом диске нет неформатировпнного пространства 4Мб до и 4Мб после раздела zfs, а есть 8Мб "unknown file system" в конце. Чем это может быть чревато? Надо ли переделывать? В Xigmanas можно раздел zfs "подвинуть" на 4Мб?

[2gusia]

>но проблем с отвалами совершенно нет
IMHO они начинаются, когда становится относительно мало свободного места. И чем меньше, тем сильнее - и наоборот

>Чем это может быть чревато?
думаю - наплевать

>В Xigmanas можно раздел zfs "подвинуть" на 4Мб?
только убить, создать новый и реплейс

[paranoicman]

я правильно понимаю, что после замены диска нужно в HDD Management удалить все диски, и заново их импортировать? А сами пулы от этого не слетят?

[2gusia]

Можно не удалять, а переимпортировать.

Пулы не слетят - их тоже можно синхронизировать если что.

Главное, чтобы сами пулы были целы - а соответствие с этой реальностью конфига xigmanas легко устанавливается