История изменений
Исправление kianvl, (текущая версия) :
И вот результат тестирования.
Два одинаковых сервера, каждый с 12 дисками по 3ТБ, ОС Linux CentOS 8.4, zfs 2.1.0. На первом сервере пул собран - zpool create -o ashift=12 pool raidz sd[a-d] raidz sd[e-h] raidz sd[i-l] На втором собираем draid - zpool create -o ashift=12 pool draid:5d:12c sd[a-l] Настройки на пулах одинаковые - zfs set recordsize=64k compression=zstd-1 mountpoint=none readonly=on pool
Первый сервер исходный, на нём тестовый раздел:
pool/test compressratio 2.50x
pool/test used 248G
pool/test logicalused 503G
Качаем его с первого на второй с опцией -c и без неё - ssh server1 /usr/sbin/zfs send -c pool/test@b | /usr/sbin/zfs recv -s pool/testc и ssh server1 /usr/sbin/zfs send pool/test@b | /usr/sbin/zfs recv -s pool/test В обоих случаях получаем интересную картину:
pool/test compressratio 1.82x
pool/test used 390G
pool/test logicalused 515G
Т.е. потери и в степени сжатия и в занятом объёме, да ещё дополнительно 12ГБ данных.
Если пересобрать на втором сервере пул так же как на первом, то при пересылке раздела (что с опцией -c что без неё) результат будет равен исходному. Т.е. ничего лишнего и сжатие нормальное. И да, опция -c действительно ускоряет пересылку раздела. В моём случае это примерно 2-2,5 раза. Таким образом видно, что вся причина в draid.
И ещё один камень в сторону draid. Рабочий бэкап сервер, для которого всё это и делалось. 16 дисков по 8ТБ. Собираем draid - zpool create -o ashift=12 pool draid:7d:16c sd[a-p] - получаем пул полезного объёма 93ТБ. Собираем аналог RAID-50 - zpool create -o ashift=12 pool raidz sd[a-h] raidz sd[i-p] - получаем пул на 98ТБ. Т.е. при использовании draid теряем ~5% полезного объёма.
Мой вывод. Для бэкап сервера, которого важен полезный объём пула, а не стабильность 24/7, draid не подходит.
Исправление kianvl, :
И вот результат тестирования.
Два одинаковых сервера, каждый с 12 дисками по 3ТБ, ОС Linux CentOS 8.4, zfs 2.1.0. На первом диске пул собран - zpool create -o ashift=12 pool raidz sd[a-d] raidz sd[e-h] raidz sd[i-l] На втором собираем draid - zpool create -o ashift=12 pool draid:5d:12c sd[a-l] Настройки на пулах одинаковые - zfs set recordsize=64k compression=zstd-1 mountpoint=none readonly=on pool
Первый сервер исходный, на нём тестовый раздел:
pool/test compressratio 2.50x
pool/test used 248G
pool/test logicalused 503G
Качаем его с первого на второй с опцией -c и без неё - ssh server1 /usr/sbin/zfs send -c pool/test@b | /usr/sbin/zfs recv -s pool/testc и ssh server1 /usr/sbin/zfs send pool/test@b | /usr/sbin/zfs recv -s pool/test В обоих случаях получаем интересную картину:
pool/test compressratio 1.82x
pool/test used 390G
pool/test logicalused 515G
Т.е. потери и в степени сжатия и в занятом объёме, да ещё дополнительно 12ГБ данных.
Если пересобрать на втором сервере пул так же как на первом, то при пересылке раздела (что с опцией -c что без неё) результат будет равен исходному. Т.е. ничего лишнего и сжатие нормальное. И да, опция -c действительно ускоряет пересылку раздела. В моём случае это примерно 2-2,5 раза. Таким образом видно, что вся причина в draid.
И ещё один камень в сторону draid. Рабочий бэкап сервер, для которого всё это и делалось. 16 дисков по 8ТБ. Собираем draid - zpool create -o ashift=12 pool draid:7d:16c sd[a-p] - получаем пул полезного объёма 93ТБ. Собираем аналог RAID-50 - zpool create -o ashift=12 pool raidz sd[a-h] raidz sd[i-p] - получаем пул на 98ТБ. Т.е. при использовании draid теряем ~5% полезного объёма.
Мой вывод. Для бэкап сервера, которого важен полезный объём пула, а не стабильность 24/7, draid не подходит.
Исправление kianvl, :
И вот результат тестирования.
Два одинаковых сервера, каждый с 12 дисками по 3ТБ, ОС Linux CentOS 8.4, zfs 2.1.0. На первом диске пул собран - zpool create -o ashift=12 pool raidz sd[a-d] raidz sd[e-h] raidz sd[i-l] На втором собираем draid - zpool create -o ashift=12 pool draid:5d:12c sd[a-l] Настройки на пулах одинаковые - zfs set recordsize=64k compression=zstd-1 mountpoint=none readonly=on pool
Первый сервер исходный, на нём тестовый раздел:
pool/test compressratio 2.50x
pool/test used 248G
pool/test logicalused 503G
Качаем его с первого на второй с опцией -c и без неё - ssh server1 /usr/sbin/zfs send -c pool/test@b | /usr/sbin/zfs recv -s pool/testc и ssh server1 /usr/sbin/zfs send pool/test@b | /usr/sbin/zfs recv -s pool/test В обоих случаях получаем интересную картину:
pool/test compressratio 1.82x
pool/test used 390G
pool/test logicalused 515G
Т.е. потери и в степени сжатия и в занятом объёме, да ещё дополнительно 12ГБ данных.
Если пересобрать на втором сервере пул так же как на первом, то при пересылке раздела (что с опцией -c что без неё) результат будет равен исходному. Т.е. ничего лишнего и сжатие нормальное. И да, опция -c действительно ускоряет пересылку раздела. В моём случае это примерно 2-2,5 раза. Таким образом видно, что вся причина в draid.
И ещё один камень в сторону draid. Рабочий бэкап сервер, для которого всё это и делалось. 16 дисков по 8ТБ. Собираем draid - zpool create -o ashift=12 pool draid:7d:16c sd[a-p] - получаем пул полезного объёма 93ТБ. Собираем аналог RAID-50 - zpool create -o ashift=12 pool raidz sd[a-h] raidz sd[i-p] - получаем пул на 98ТБ. Т.е. при использовании draid теряем ~5% полезного объёма.
Мой вывод. Для бэкап сервера, который не загружен 24/7, а лишь периодически обновляет снэпшоты, draid не подходит.
Исправление kianvl, :
И вот результат тестирования.
Два одинаковых сервера, каждый с 12 дисками по 3ТБ, ОС Linux CentOS 8.4, zfs 2.1.0. На первом диске пул собран - zpool create -o ashift=12 pool raidz sd[a-d] raidz sd[e-h] raidz sd[i-l] На втором собираем draid - zpool create -o ashift=12 pool draid:5d:12c sd[a-l] Настройки на пулах одинаковые - zfs set recordsize=64k compression=zstd-1 mountpoint=none readonly=on pool
Первый сервер исходный, на нём тестовый раздел:
pool/test compressratio 2.50x
pool/test used 248G
pool/test logicalused 503G
Качаем его с первого на второй с опцией -c и без неё - ssh server1 /usr/sbin/zfs send -c pool/test@b | /usr/sbin/zfs recv -s pool/testc и ssh server1 /usr/sbin/zfs send pool/test@b | /usr/sbin/zfs recv -s pool/test В обоих случаях получаем интересную картину:
pool/test compressratio 1.82x
pool/test used 390G
pool/test logicalused 515G
Т.е. потери и в степени сжатия и в занятом объёме, да ещё дополнительно 12ГБ данных.
Если пересобрать на втором сервере пул так же как первом, то при пересылке раздела (что с опцией -c что без неё) результат будет равен исходному. Т.е. ничего лишнего и сжатие нормальное. И да, опция -c действительно ускоряет пересылку раздела. В моём случае это примерно 2-2,5 раза. Таким образом видно, что вся причина в draid.
И ещё один камень в сторону draid. Рабочий бэкап сервер, для которого всё это и делалось. 16 дисков по 8ТБ. Собираем draid - zpool create -o ashift=12 pool draid:7d:16c sd[a-p] - получаем пул полезного объёма 93ТБ. Собираем аналог RAID-50 - zpool create -o ashift=12 pool raidz sd[a-h] raidz sd[i-p] - получаем пул на 98ТБ. Т.е. при использовании draid теряем ~5% полезного объёма.
Мой вывод. Для бэкап сервера, который не загружен 24/7, а лишь периодически обновляет снэпшоты, draid не подходит.
Исходная версия kianvl, :
И вот результат тестирования.
Два одинаковых сервера, каждый с 12 дисками по 3ТБ, ОС Linux CentOS 8.4, zfs 2.1.0. На первом диске пул собран - zpool create -o ashift=12 pool raidz sda sdb sdc sdd raidz sde sdf sdg sdh raidz sdi sdj sdk sdl На втором собираем draid - zpool create -o ashift=12 pool draid:5d:12c sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl Настройки на пулах одинаковые - 2021-07-27.00:47:24 zfs set recordsize=64k compression=zstd-1 mountpoint=none readonly=on pool
Первый сервер исходный, на нём тестовый раздел:
pool/test compressratio 2.50x
pool/test used 248G
pool/test logicalused 503G
Качаем его с первого на второй с опцией -c и без неё - ssh server1 /usr/sbin/zfs send -c pool/test@b | /usr/sbin/zfs recv -s pool/testc и ssh server1 /usr/sbin/zfs send pool/test@b | /usr/sbin/zfs recv -s pool/test В обоих случаях получаем интересную картину:
pool/test compressratio 1.82x
pool/test used 390G
pool/test logicalused 515G
Т.е. потери и в степени сжатия и в занятом объёме, да ещё дополнительно 12ГБ данных.
Если пересобрать на втором сервере пул так же как первом, то при пересылке раздела (что с опцией -c что без неё) результат будет равен исходному. Т.е. ничего лишнего и сжатие нормальное. И да, опция -c действительно ускоряет пересылку раздела. В моём случае это примерно 2-2,5 раза. Таким образом видно, что вся причина в draid.
И ещё один камень в сторону draid. Рабочий бэкап сервер, для которого всё это и делалось. 16 дисков по 8ТБ. Собираем draid - zpool create -o ashift=12 pool draid:7d:16c sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl sdm sdn sdo sdp - получаем пул полезного объёма 93ТБ. Собираем аналог RAID-50 - zpool create -o ashift=12 pool raidz sda sdb sdc sdd sde sdf sdg sdh raidz sdi sdj sdk sdl sdm sdn sdo sdp - получаем пул на 98ТБ. Т.е. при использовании draid теряем ~5% полезного объёма.
Мой вывод. Для бэкап сервера, который не загружен 24/7, а лишь периодически обновляет снэпшоты, draid не подходит.