@radjah Я думаю, ещё вырастет.
Это же ребилд RAID 5 из трёх дисков по 10 ТБ на RAID 6 из пяти дисков по 10 ТБ.

@skobkin А по IO не сильно жопа, или у тебя не критично?

@radjah
Уточни, что именно ты имеешь в виду?

@skobkin Ну дисковая подсистема сейчас должна быть хорошо так нагружена. На остальном населении сервера это сильно сказывается?

@radjah Остальное население сервера - это в основном я.
Остальных я просто предупредил, что он будет недоступен какое-то время.
Можно было, в принципе, не предупреждать. Но я решил ускорить процесс и погасить всё, что на этот рейд ходит.

В целом, думаю, можно было бы не сильно увеличивать срок погасив только Transmission (~800 торрентов), т.к. медиасервер и прочие не постоянно дёргают диск. А базы данных на SSD отдельном вертятся.

Но я решил, что поживу без сериалов и анимы пару дней.

Величайшие жертвы во имя производительности!

@skobkin Медиасервер линейно же читает и базу по идее по inotify обновляет. Хотя может в логи срать, да.

@radjah
Да. И с приличным кэшем он радикально бы время не менял. В логи срёт только когда кто-то что-то делает с ним, и то немного.
А вот Transmission, который по мелким кусочкам дёргает в тыще мест - это беда. Там почти гигабайтный файловый кеш настроен, но он больше всего влияет на скачивание, а там сидирование.
Впрочем, я не проверял, конечно, на степень влияния.

Помню что когда собирал RAID 5 - уже во время сборки массива на него всё переливал и юзал медиасервер.

@skobkin Про трансмиссию я специально не писал, потому что у меня 4-я малина в качестве примера отлипания дисковой системы после выключения сервиса. :)

@radjah
Да, я в своё время у себя на сервере подобную проблему решал.
Спасло то, что во-первых не малина, ну и твик файлового кэша вместе с переездом на RAID, который распределил нагрузку по дискам ровнее.
У меня, кстати, поверх этого рейда ещё и LUKS 😆

@skobkin Тю! Я когда хард один клонировал через eSATA, он у меня через два переходника и кабель был подключен.
Так-то я на него дышать боялся. :)

@radjah
Ну, тут все уже склонировано.
В целом можно прямо сейчас их выдернуть - нифига не случится. Два из них, скорее всего, вообще спят.

@skobkin
Looks legit

@skobkin
Сервер @uu очень похоже выглядит

@drq @uu
Ну, мой обычно закрыт. Да и постоянные диски там с обратной стороны в специальных корзинах рядами сидят.
Или ты про развал на колонке, а про корпус-куб?

@skobkin
Не, я про развал :)
@uu

@drq @uu
Это на пару дней только :)
Правда, вот развал во всей окружающей комнате - это надолго 😄

@skobkin По ману "reshaping" - это как раз и есть изменение размера. У тебя там один большой раздел на 20ТБ был?

Ну в первом сообщение у тебя сразу было [UUU_U]

@radjah
> По ману "reshaping" - это как раз и есть изменение размера

Ну чот да, я пропустил этот момент.
Но, опять же, есть подозрение, что мне к моему:
--grow /dev/x --level=6 --raid-devices=5

Надо было ещё --array-size=max добавить.
Ладно, посмотрим что будет через пару дней когда оно закончится.

> Ну в первом сообщение у тебя сразу было [UUU_U]

Ну да. Я практически сразу после того постика и посмотрел на размер.

@radjah Там, кстати, ещё в LEVEL CHANGES написано, что смена уровня - тоже решейпинг.
> reshaping a 3-drive RAID5 into a 4-drive RAID6

Ну, по крайней мере это логично звучит там, где формат контрольных сумм меняется.

@skobkin Я маны погуглил по mdadm. Там везде пишут, что после такого изменения надо grow делать.

> Надо было ещё --array-size=max добавить.

Это сразу grow делает?

@radjah
У меня и так grow. Но без --array-size был.
Или я не понял, что ты хотел сказать.

@radjah
> У тебя там один большой раздел на 20ТБ был?

Да.

@skobkin ext4 или что-то особое?

@radjah
MDRAID > LUKS > EXT4
Наращу первый - дальше особо не должно быть проблем: LUKS в принципе пофигу, а EXT4 растянуть несложно.

@radjah Полтора часа, чо.

@radjah Уиии!
Оно закончилось и всё сделало само без лишних пинков:

> Raid Level : raid6
> Array Size : 29297341440 (27940.12 GiB 30000.48 GB)
> Raid Devices : 5
> Total Devices : 5
> State : clean
> Layout : left-symmetric

☺️

@skobkin Поздравляю, чо. 😁