Медленный доступ к btrfs на LVM/
Необходимо использовать массив вместо строки:
args=("a" "b c")
./2.sh "${args[@]}"
Когда расширение массива заключается в кавычки, каждый элемент массива правильно расширен.
Я не могу комментировать, извините, если это не хорошо, как ответ. Вы должны проверить ваши диски. Я думаю, что 12 дней Rsync Time для 10 ТБ слишком долго, должно быть более 12-24 часа. Посмотрите на разные диски с помощью SmartCTL, чтобы проверить, имеет ли у кого-то много ошибок:
for i in a b c d e f g h i j k l; do echo $i ; smartctl -x /dev/sd$i | grep occurred | head -1 ; done
Я видел, как работает RAID замедляется из-за этого. И IIRC BTRFS нуждается в большем доступе диска, чем Ext4 для Diagatory UPS, что может объяснить разницу скорости доступа.
Вы только что уложили три слоя на диске ввода / вывода, и вам интересно, почему он плохо работает?
Есть старая поговорка в информатике, приписываемой Дэвидом Уилер :
Любая проблема в информатике может быть решена с другим слоем косвенности.
Это не так. Существует одна проблема, которую вы не можете решить так: система слишком медленная. (Не при добавлении более аппаратного обеспечения в любом случае. Больше шпинделей в этом случае или кластеризация или балансировка нагрузки и т. Д.)
BTRFS включает функциональность LVM, но вы ушли и сложили, что на вершине Linux Слой LVM2 и положить , что на вершине аппаратной системы RAID-6. Что еще вы сделали, принимали виртуальные машины на этой резервированной кучу абстракции, чтобы вы могли добавить еще один слой или два косвествия файловой системы?
Вы просили советы, так вот мой: Snap некоторые из этих слоев.
Если бы это был я, я бы настроил аппаратную дисковую подсистему для JBOD и положите BTRF напрямую через него.
Более широко, вы не должны ожидать, что BTRF достигают того же выступления, что и Ext [234] . Вы не сравниваете яблоки к яблокам. BTRFS покупает вам более высокий уровень целостности данных, поэтому, естественно, будет работать немного медленнее. Tanstaafl .