Что?

Я так понимаю это hetzner? Учитывая, что про восстановление или какие сетевые адаптеры (и смогут ли они прокачать этот трафик) пока что нет ни слова

Есть только одна проблема. Время ребилда.

Ну и конечно же отсутствие hotspare и я не вижу ничего про мониторинг дисков

Здравствуйте, All! Подскажите пожалуйста, как оптимальнее всего настроить сервер с ZFS, чтобы была прежде всего максимальная надежность хранения данных и вторым по приоритетности - максимальная скорость работы, но не в ущерб надежности и стабильности. Технические параметры сервера Процессор AMD Ryzen 9 3900 12-Core Processor Память 128 GiB DDR4 ECC Подсистема хранения 2 x 1.92 TB (Gen 3) NVMe + 8 x 22 TB SATA 6Gb/s 7200 rpm Операционная система Rocky Linux 9.5 + zfs-2.1.16 Планирую сделать один RAIDZ2 vdev из всех этих 8 HDD каждый из которых имеет размер 20 TiB (или 22 TB, другими словами). zpool create -o ashift=12 -O compression=lz4 -O atime=off -O xattr=sa -O acltype=posix tank raid2 ... Это выделенный сервер у которого только одна роль - backup server, куда будут писаться через ssh zfs send ...| zfs recv ... в постоянном режиме все датасеты со всех серверов (постоянная репликация с паузой между повторными попытками в 10 минут). Датасеты с удаленных серверов - это в основном sparse zvol размером 64 TiB с volblocksize=16K и данными на XFS внутри zvol. ARC займет своих 50% оперативной памяти или даже 80%. L2ARC не вижу смысла вообще делать, потому что на этот сервер будут в основном только писать, а читать будут очень редко - когда надо будет что-то восстановить из резервных копий. special device на NVMe тоже не вижу смысла делать, потому что это значительно уменьшит надежность файловой системы и увеличит ее хрупкость, даже если бы это и дало какой-то небольшой прирост производительности при записи на диски. При такой конфигруации - если делать из 8 HDD на 20 TiB один RAIDZ2 vdev - два HDD уйдут на контрольные суммы и примерно 120 TiB будет доступного места на диске. Если в такой конфигурации сервер не будет справляться с нагрузкой на запись - тогда наверное единственным вариантом будет сделать два RAIDZ2 vdev каждый по 4 диска, тогда на контрольные суммы уйдет 4 диска и полезный объем пула будет 80 TiB, но при этом - будет в два раза выше производительность дисковой подсистемы, потому что будет два RAIDZ2 vdev вместо одного. RAIDZ3 vdev из 8 HDD наверное нет смысла делать, потому что это еще сильнее уменьшит производительность дисковой подсистемы по сравнению с RAIDZ2 vdev. А надежность у RAIDZ2 vdev вполне достаточная для выполнения этой задачи. Что не могу пока что понять: Если поставить logbias=throughput то в man странице написано, что в таком случае SLOG вообще не будет использоваться. А если поставить logbias=latency (по умолчанию) тогда будет использоваться SLOG для записи synchronous requests. Но не понятно, когда 100% операций записи на zfs pool производит команда zfs receive - есть ли тогда synchronous requests и какой именно размер SLOG будет самым оптимальным для такого zpool ? Или имеет смысл просто поставить logbias=throughput и забыть про эту проблему с SLOG (он же ZIL) и L2ARC вообще? Возможно есть еще какие-то варианты и способы как выжать максимум производительности из файловой системы ZFS на этом сервере, обладающего таким hardware, возможно про какие-то еще настройки zpool для оптимизации производительности я забыл ? tuned profile на этом сервере установлен в network-latency - Optimize for deterministic performance at the cost of increased power consumption, focused on low latency network performance.

hotspare мне здесь не нужен, сбойный диск на новый в датацентре меняют достаточно быстро по заявке. тем более, что здесь же RAIDZ2 vdev, так что этот сервер может пережить без потери данных даже одновременный выход из строя двух жестких дисков, поэтому я не вижу смысла здесь использовать hotspare. мониторинг дисков стандартный, через zed и smartd. man zed man smartd и zed и smartd присылают уведомление емейлом в случае проблем с каким-то из дисков.

- для сервера бекапов вам релиз 2.2 точно ок уже, это же копии. Там была оптимизация перфа - для канала в 1гбит/с вам много перфа и не надо, raidz2 не самый быстрый но чуть более надёжный, как вы и хотите - т.к. вы будете пересылать снапшоты, то другой тюнинг и не нужен (он по бОльшей части игнорится и переопределяется для снапов присланных), лучше изучите как эффективнее zfs send-recv делать, посмотрите на ключи -Lec и тд, гляньте на какой-нибудь zrepl и его доку

у zfs send -L как раз важен, если вы используете сжатие на источнике, чтобы данные как есть летели по сети а не разжимались. Я видел у одного знакомого хостера кейс, когда коэффициент сжатия был 1800, 2Гбайта сжатых лились на сервер бекапа как несколько ТБ))

- для сервера бекапов вам релиз 2.2 точно ок уже, это же копии. Там была оптимизация перфа - для канала в 1гбит/с вам много перфа и не надо, raidz2 не самый быстрый но чуть более надёжный, как вы и хотите - т.к. вы будете пересылать снапшоты, то другой тюнинг и не нужен (он по бОльшей части игнорится и переопределяется для снапов присланных), лучше изучите как эффективнее zfs send-recv делать, посмотрите на ключи -Lec и тд, гляньте на какой-нибудь zrepl и его доку

- для сервера бекапов вам релиз 2.2 точно ок уже, это же копии. Там была оптимизация перфа - для канала в 1гбит/с вам много перфа и не надо, raidz2 не самый быстрый но чуть более надёжный, как вы и хотите - т.к. вы будете пересылать снапшоты, то другой тюнинг и не нужен (он по бОльшей части игнорится и переопределяется для снапов присланных), лучше изучите как эффективнее zfs send-recv делать, посмотрите на ключи -Lec и тд, гляньте на какой-нибудь zrepl и его доку

- для сервера бекапов вам релиз 2.2 точно ок уже, это же копии. Там была оптимизация перфа Насколько большим может быть прирост производительности работы файловой системы после перехода с 2.1.16 на 2.2.7 ? "оптимизации перфа" - да, но в плане стабильности и надежности работы - лучше когда и на продовых серверах и на бекапном сервере используется одинаковая версия zfs - тогда меньше будет возможных сюрпризов и возможных проблем. Т.е. переход на 2.2 на бекапном сервере я понимаю как trade-off, когда увеличивается производительность путем уменьшения надежности. Идти по такому пути не очень хочется, тем более, что я и так уже нарушаю правило бекапов 3-2-1, используя только zfs send | zfs recv для бекапов и два идентичных сервера в разных датацентрах для резервных копий, поэтому еще большее уменьшение надежности резервных копий - крайне нежелательно. Я бы и рад не нарушать правило 3-2-1, но чем и куда кроме zfs send | zfs recv бекапить десятки и сотни sparse zvol размером по 64 TiB каждый? На каждом zvol - файловая система XFS и количество данных на каждом zvol примерно от 0 до 5 терабайт. - т.к. вы будете пересылать снапшоты, то другой тюнинг и не нужен (он по бОльшей части игнорится и переопределяется для снапов присланных), лучше изучите как эффективнее zfs send-recv делать, посмотрите на ключи -Lec и тд, гляньте на какой-нибудь zrepl и его доку видел, что hxxps : // github . com / jimsalterjrs/sanoid использует mbuffer для увеличения производительности. Наверное использование mbuffer (низкий риск проблем) и использование ключей -Lec (средний/высокий риск проблем(?)) будет достаточными способами для повышения производительности, и мощности этого сервера после таких оптимизаций должно хватить для текущей нагрузки. Сначала использовать mbuffer, но если этого будет не достаточно - тогда уже и -Lec придется включать. у zfs send -L как раз важен, если вы используете сжатие на источнике, чтобы данные как есть летели по сети а не разжимались. Так у меня де в основном используются zvol и там volblocksize=16К, так что откуда там могут появиться large blocks, которые больше чем 128К в размере? тем более, что в документации предупреждается о возможных проблемах и data corruption, если с одной стороны указать ключ --large-block а с другой стороны - не указать: https : // openzfs . github . io /openzfs-docs/Project%20and%20Community/FAQ.html#sending-large-blocks Компрессию то включить можно, но основная статика - это картинки .jpg и тому подобные форматы - эти данные не сжимаемые вообще, так что включение компрессии при пересылке snapshot`ов особо какого-то выиграша в производительности не даст. Тем более, что они (снапшоты) создаются раз в час и объем данных для передачи, что накапливается за один час - сравнительно небольшой, тем более что там происходит incremental zfs send, то есть - передается только небольшой diff между двумя соседними снапшотами - так что весь траффик между основным и бекапным сервером равномерно размазан по времени и такая репликация происходит постоянно, 24 часа в сутки. Сеть не является узким местом, потому что 1 гигабит - это примерно 100 мегабайт в секунду, такой пропускной способности должно хватить для нормальной работы. Меня больше интересует вопрос максимальной производительности дисковой подсистемы - чтобы выжать из RAIDZ2 vdev максимум возможной производительности, но не ценой снижения надежности. Некоторые diff`ы между соседними снапшотами передаются буквально за несколько секунд или десятков секунд. Просто дисковая под система бекапного сервера уже начинает не справляться с нагрузкой, когда на один бекапный сервер приходят данные с большого количества (несколько десятков) продовых серверов. то есть - просто не хватает пропускной способности дисковой подсистемы в плане IOPS и дисковая подсистема тормозит:

- для сервера бекапов вам релиз 2.2 точно ок уже, это же копии. Там была оптимизация перфа Насколько большим может быть прирост производительности работы файловой системы после перехода с 2.1.16 на 2.2.7 ? "оптимизации перфа" - да, но в плане стабильности и надежности работы - лучше когда и на продовых серверах и на бекапном сервере используется одинаковая версия zfs - тогда меньше будет возможных сюрпризов и возможных проблем. Т.е. переход на 2.2 на бекапном сервере я понимаю как trade-off, когда увеличивается производительность путем уменьшения надежности. Идти по такому пути не очень хочется, тем более, что я и так уже нарушаю правило бекапов 3-2-1, используя только zfs send | zfs recv для бекапов и два идентичных сервера в разных датацентрах для резервных копий, поэтому еще большее уменьшение надежности резервных копий - крайне нежелательно. Я бы и рад не нарушать правило 3-2-1, но чем и куда кроме zfs send | zfs recv бекапить десятки и сотни sparse zvol размером по 64 TiB каждый? На каждом zvol - файловая система XFS и количество данных на каждом zvol примерно от 0 до 5 терабайт. - т.к. вы будете пересылать снапшоты, то другой тюнинг и не нужен (он по бОльшей части игнорится и переопределяется для снапов присланных), лучше изучите как эффективнее zfs send-recv делать, посмотрите на ключи -Lec и тд, гляньте на какой-нибудь zrepl и его доку видел, что hxxps : // github . com / jimsalterjrs/sanoid использует mbuffer для увеличения производительности. Наверное использование mbuffer (низкий риск проблем) и использование ключей -Lec (средний/высокий риск проблем(?)) будет достаточными способами для повышения производительности, и мощности этого сервера после таких оптимизаций должно хватить для текущей нагрузки. Сначала использовать mbuffer, но если этого будет не достаточно - тогда уже и -Lec придется включать. у zfs send -L как раз важен, если вы используете сжатие на источнике, чтобы данные как есть летели по сети а не разжимались. Так у меня де в основном используются zvol и там volblocksize=16К, так что откуда там могут появиться large blocks, которые больше чем 128К в размере? тем более, что в документации предупреждается о возможных проблемах и data corruption, если с одной стороны указать ключ --large-block а с другой стороны - не указать: https : // openzfs . github . io /openzfs-docs/Project%20and%20Community/FAQ.html#sending-large-blocks Компрессию то включить можно, но основная статика - это картинки .jpg и тому подобные форматы - эти данные не сжимаемые вообще, так что включение компрессии при пересылке snapshot`ов особо какого-то выиграша в производительности не даст. Тем более, что они (снапшоты) создаются раз в час и объем данных для передачи, что накапливается за один час - сравнительно небольшой, тем более что там происходит incremental zfs send, то есть - передается только небольшой diff между двумя соседними снапшотами - так что весь траффик между основным и бекапным сервером равномерно размазан по времени и такая репликация происходит постоянно, 24 часа в сутки. Сеть не является узким местом, потому что 1 гигабит - это примерно 100 мегабайт в секунду, такой пропускной способности должно хватить для нормальной работы. Меня больше интересует вопрос максимальной производительности дисковой подсистемы - чтобы выжать из RAIDZ2 vdev максимум возможной производительности, но не ценой снижения надежности. Некоторые diff`ы между соседними снапшотами передаются буквально за несколько секунд или десятков секунд. Просто дисковая под система бекапного сервера уже начинает не справляться с нагрузкой, когда на один бекапный сервер приходят данные с большого количества (несколько десятков) продовых серверов. то есть - просто не хватает пропускной способности дисковой подсистемы в плане IOPS и дисковая подсистема тормозит:

Не стоит доверять смарту Лучше доверяйте уровню задержки отклика от диска

А Вы гляньте какие блоки у Вас сейчас записаны

Так насколько я помню zfs не даёт создание degrade pool из одного диска. Или сейчас он уже это умеет?

Вы предлагаете самостоятельно мониторить состояние zpool iostat -pw или каким способом Вы предлагаете "доверять уровню задержек отклика от диска" ? так вроде бы подобные проверки уже встроены в файловую систему и это работает автоматически, и если какой-то диск из zfs pool будет очень медленно работать - ZED это должен увидеть и сообщить об этом, разве нет?

Вы предлагаете самостоятельно мониторить состояние zpool iostat -pw или каким способом Вы предлагаете "доверять уровню задержек отклика от диска" ? так вроде бы подобные проверки уже встроены в файловую систему и это работает автоматически, и если какой-то диск из zfs pool будет очень медленно работать - ZED это должен увидеть и сообщить об этом, разве нет?

16K размер блока. # zfs get all tank/mirror/server-name/volume-name | grep vol tank/mirror/server-name/volume-name type volume - tank/mirror/server-name/volume-name volsize 64.0T local tank/mirror/server-name/volume-name volblocksize 16K - tank/mirror/server-name/volume-name volmode default default

@makhomed и Александр И. Если не разбираетесь в вопросе, зачем лезть с советами? Вы пишите полную ересь, сами не читали доку, зато другого отправляете. @serg78ant так, как вы хотели сделать изначально, можно сделать, не слушайте недоучек) Хотя Алексей уже дал инструкцию, как сделать

16K размер блока. # zfs get all tank/mirror/server-name/volume-name | grep vol tank/mirror/server-name/volume-name type volume - tank/mirror/server-name/volume-name volsize 64.0T local tank/mirror/server-name/volume-name volblocksize 16K - tank/mirror/server-name/volume-name volmode default default

Вот так приходит кто-то считающий что знает больше чем ты, пусть даже если это и так, оскорбит и потом вообще не захочешь кому-то помогать в чате. Можно же просто написать что человек ошибается, кажется так ведь учатся.

Дык для разжатых данных по сети всегда есть ssh c компрессией или даже zstd в пайпе

@makhomed и Александр И. Если не разбираетесь в вопросе, зачем лезть с советами? Вы пишите полную ересь, сами не читали доку, зато другого отправляете. @serg78ant так, как вы хотели сделать изначально, можно сделать, не слушайте недоучек) Хотя Алексей уже дал инструкцию, как сделать

@makhomed и Александр И. Если не разбираетесь в вопросе, зачем лезть с советами? Вы пишите полную ересь, сами не читали доку, зато другого отправляете. Да, действительно в файловой системе OpenZFS можно конвертировать pool состоящий из одного диска в mirror с помощью команды zpool attach - я об этом не знал раньше, потому что никогда не создавал zfs pool состоящий из одного диска, всегда с самого начала только mirror или raidz2 из нескольких дисков. # man zpool attach NAME zpool-attach — attach new device to existing ZFS vdev SYNOPSIS zpool attach [-fsw] [-o property=value] pool device new_device DESCRIPTION Attaches new_device to the existing device. The existing device cannot be part of a raidz configuration. If device is not currently part of a mirrored configuration, device automatically transforms into a two-way mirror of device and new_device. If device is part of a two-way mirror, attaching new_device creates a three-way mirror, and so on. In either case, new_device begins to resilver immediately and any running scrub is cancelled. Причем, такая возможность конвертации одиночного диска в mirror была даже в старой версии ZFS от Sun Microsystems, так что все версии OpenZFS это умеют делать - дизайн файловой системы ZFS даже лучше, чем я этого ожидал от нее изначально. Для обычных файловых систем в Linux такая конвертация single disk в mrdaid RAID-1 mirror невозможна, потому что для mdraid необходимо дополнительное место на диске для metadata. А в ZFS / OpenZFS такая возможность конвертации "на лету", оказывается предусмотрена уже изначально в дизайне файловой системы, с самого начала. Удобная возможность. Спасибо, что указали на эту мою ошибку / неточность - я про эту возможность не знал раньше, теперь буду знать. @makhomed и Александр И. Если не разбираетесь в вопросе, зачем лезть с советами? Вы пишите полную ересь Тот способ, про который я написал в своем первом сообщении - он тоже рабочий, просто там есть несколько дополнительных (лишних) шагов, в которых, как теперь выяснилось, нет необходимости. Но способ тоже рабочий. @makhomed и Александр И. Если не разбираетесь в вопросе, зачем лезть с советами? А что не так с моим советом использовать Whole Disk для ZFS вместо ручного создания разделов для файловой системы?

@makhomed и Александр И. Если не разбираетесь в вопросе, зачем лезть с советами? Вы пишите полную ересь, сами не читали доку, зато другого отправляете. Да, действительно в файловой системе OpenZFS можно конвертировать pool состоящий из одного диска в mirror с помощью команды zpool attach - я об этом не знал раньше, потому что никогда не создавал zfs pool состоящий из одного диска, всегда с самого начала только mirror или raidz2 из нескольких дисков. # man zpool attach NAME zpool-attach — attach new device to existing ZFS vdev SYNOPSIS zpool attach [-fsw] [-o property=value] pool device new_device DESCRIPTION Attaches new_device to the existing device. The existing device cannot be part of a raidz configuration. If device is not currently part of a mirrored configuration, device automatically transforms into a two-way mirror of device and new_device. If device is part of a two-way mirror, attaching new_device creates a three-way mirror, and so on. In either case, new_device begins to resilver immediately and any running scrub is cancelled. Причем, такая возможность конвертации одиночного диска в mirror была даже в старой версии ZFS от Sun Microsystems, так что все версии OpenZFS это умеют делать - дизайн файловой системы ZFS даже лучше, чем я этого ожидал от нее изначально. Для обычных файловых систем в Linux такая конвертация single disk в mrdaid RAID-1 mirror невозможна, потому что для mdraid необходимо дополнительное место на диске для metadata. А в ZFS / OpenZFS такая возможность конвертации "на лету", оказывается предусмотрена уже изначально в дизайне файловой системы, с самого начала. Удобная возможность. Спасибо, что указали на эту мою ошибку / неточность - я про эту возможность не знал раньше, теперь буду знать. @makhomed и Александр И. Если не разбираетесь в вопросе, зачем лезть с советами? Вы пишите полную ересь Тот способ, про который я написал в своем первом сообщении - он тоже рабочий, просто там есть несколько дополнительных (лишних) шагов, в которых, как теперь выяснилось, нет необходимости. Но способ тоже рабочий. @makhomed и Александр И. Если не разбираетесь в вопросе, зачем лезть с советами? А что не так с моим советом использовать Whole Disk для ZFS вместо ручного создания разделов для файловой системы?

Пункт 1. mdadm --create --verbose /dev/md0 --level=mirror --raid-devices=2 /dev/sdb1 missing Пункт 2. Raid0 —> Raid5 —> Raid1 допустимо

Потому что это дело вкуса. Человек не читал документацию, поэтому чем более классическое решение ему будет предложено - тем лучше. С учётом остальных тейков с твоей стороны - *Плохой совет иногда хуже чем просто промолчать*

mdadm --create --verbose /dev/md0 --level=mirror --raid-devices=2 /dev/sdb1 missing здесь с самого начала создается mdraid и соответственно - резервируется место под метаданные. я говорил про тот случай когда есть только один диск, на нем - обычный раздел и на этом разделе уже создана файловая система и лежат данные. в такой ситуации - конвертировать "на лету" single disk в mdraid невозможно.

не путайте, zfs send -L не сжимает, он не РАЗЖИМАЕТ если данные были сжаты и передаёт как есть, я про это

Vladislav Losev, [20.12.2024 14:43] Потому что это дело вкуса. Человек не читал документацию, поэтому чем более классическое решение ему будет предложено - тем лучше. С учётом остальных тейков с твоей стороны - *Плохой совет иногда хуже чем просто промолчать* Vladislav Losev, [20.12.2024 14:45] Если ты не знаешь плюсов и минусов почему стоит\не стоит выдавать разделы вместо whole disk (хотя бы базовый /dev/disk/by-partuuid) - то не стоит высказывать это. ИМХО - разницы никакой, но только если человек ПОНИМАЕТ почему он делает так, а не иначе а в чем преимущества варианта когда вручную создается раздел на весь диск и этот раздел отдается ZFS ? я у такого варианта вижу одни только недостатки и ни одного преимущества. Вариант использования Whole Disk для ZFS имеет несколько преимуществ, о которых я уже говорил раньше. Поэтому - по возможности именно этот вариант - Whole Disk и рекомендуется использовать в документации к ZFS.

Ну если проблема только в том сколько надо передать по сети, то пожалуй zstd в пайпе жать будет лучше чем сугубо поблочное zfs

Зато большая экономия процессорного времени обоих машин

mdadm --create --verbose /dev/md0 --level=mirror --raid-devices=2 /dev/sdb1 missing здесь с самого начала создается mdraid и соответственно - резервируется место под метаданные. я говорил про тот случай когда есть только один диск, на нем - обычный раздел и на этом разделе уже создана файловая система и лежат данные. в такой ситуации - конвертировать "на лету" single disk в mdraid невозможно.

Vladislav Losev, [20.12.2024 14:43] Потому что это дело вкуса. Человек не читал документацию, поэтому чем более классическое решение ему будет предложено - тем лучше. С учётом остальных тейков с твоей стороны - *Плохой совет иногда хуже чем просто промолчать* Vladislav Losev, [20.12.2024 14:45] Если ты не знаешь плюсов и минусов почему стоит\не стоит выдавать разделы вместо whole disk (хотя бы базовый /dev/disk/by-partuuid) - то не стоит высказывать это. ИМХО - разницы никакой, но только если человек ПОНИМАЕТ почему он делает так, а не иначе а в чем преимущества варианта когда вручную создается раздел на весь диск и этот раздел отдается ZFS ? я у такого варианта вижу одни только недостатки и ни одного преимущества. Вариант использования Whole Disk для ZFS имеет несколько преимуществ, о которых я уже говорил раньше. Поэтому - по возможности именно этот вариант - Whole Disk и рекомендуется использовать в документации к ZFS.

Vladislav Losev, [20.12.2024 14:43] Потому что это дело вкуса. Человек не читал документацию, поэтому чем более классическое решение ему будет предложено - тем лучше. С учётом остальных тейков с твоей стороны - *Плохой совет иногда хуже чем просто промолчать* Vladislav Losev, [20.12.2024 14:45] Если ты не знаешь плюсов и минусов почему стоит\не стоит выдавать разделы вместо whole disk (хотя бы базовый /dev/disk/by-partuuid) - то не стоит высказывать это. ИМХО - разницы никакой, но только если человек ПОНИМАЕТ почему он делает так, а не иначе а в чем преимущества варианта когда вручную создается раздел на весь диск и этот раздел отдается ZFS ? я у такого варианта вижу одни только недостатки и ни одного преимущества. Вариант использования Whole Disk для ZFS имеет несколько преимуществ, о которых я уже говорил раньше. Поэтому - по возможности именно этот вариант - Whole Disk и рекомендуется использовать в документации к ZFS.

Всех приветствую. Не могу ни как разобраться с zvol... С ZFS познакомился недавно, в свете организации семейного файлового хранилища чисто для дома. Есть ПК, который выделил под, скажем так, сервер. Хотел использовать на нем proxmox, но потом передумал, т.к. комп не особо шустрый. Решил ограничиться установкой Ubuntu 24.04 и несколькими виртуальными машинами в virtualbox и организацией mirror на zfs. Для этого у меня есть 2 жёстких по 1ТБ. На одном из них (sdс) есть накопленная годами информация около 350Гб. Перенести мне её, на время создания зеркала , некуда. И вот в чем у меня затык: Начитавшись, что лучше создавать пулы из блочных устройств, удалил с пустого sdb все разделы (вместе с таблицей разделов) и создал из него zpool. Назовем его, как в различной документации, "tank". Ни какие датасеты и файловые системы я на нем не делал. Затем перенес данные семейного архива с обычного (ext4) sdc на новоиспечённый zfs-ный sdb. Далее мне нужно присоединить sdc к sdb и зазеркалить их, с сохранением данных. Для этого очистил sdc - удалив с него все разделы и таблицу разделов. А вот что дальше сделать мне не понятно. Где-то пишут, что нужно делать attach, где-то пишут, что надо сначала делать add и затем create, а где-то пишут о простом add с параметром mirror. В конец запутался. Может уже плюнуть на хорошести связанные с использованием блочных устройств и переделать все на vdev - создать таблицы разделов gpt, создать по разделу на каждом из дисков и объединять в зеркало уже их? Не понимаю. Помогите пожалуйста.

При этом в документации ZFS есть инструкция, как разбить диск на части, чтобы один раздел использовать для пула с ограниченными возможностями, чтобы с него grub мог загрузиться, а второй уже для остальных данных @a_d_m_i_n_S, в исходном вопросе разговор был про сервер с тремя дисками, sda на котором установлена система, и два диска - sdb и sdc размером по 1 терабайту для файлового хранилища. поэтому в такой ситуации именно выделение для ZFS дисков в режиме Whole Disk является наиболее целесообразным и наиболее удобным в работе вариантом. про то, что надо использовать полные имена дисков из /dev/disk/by-id а не короткие имена /dev/sdb и /dev/sdc - про это в документации к ZFS написано, в ZFS FAQ: hxxps : // openzfs . github . io / openzfs-docs/Project%20and%20Community/FAQ.html#selecting-dev-names-when-creating-a-pool-linux

Я посмотрю как ты будешь тестировать диск на чтение\запись для проверки его деградации когда у тебя нет отдельного раздела для этого

Если это zfs mirror или любой raidz -- запросто. zfs потом всё отресилверит :)

Я посмотрю как ты будешь тестировать диск на чтение\запись для проверки его деградации когда у тебя нет отдельного раздела для этого

Я посмотрю как ты будешь тестировать диск на чтение\запись для проверки его деградации когда у тебя нет отдельного раздела для этого мне удобнее благодаря использованию Whole Disk иметь возможность менять сбойный диск одной командой и удобнее иметь более высокую производительность дисковой подсистемы из-за автоматического переключения /sys/block/sdX/queue/scheduler из режима [mq-deadline] в режим [none]. отдельный раздел, размером 8 мегабайт, кстати, ZFS создает при использовании диска в режиме Whole Disk. возможно что именно для этих целей - чтобы была возможность проводить тесты скорости чтения и записи.

Я посмотрю как ты будешь тестировать диск на чтение\запись для проверки его деградации когда у тебя нет отдельного раздела для этого мне удобнее благодаря использованию Whole Disk иметь возможность менять сбойный диск одной командой и удобнее иметь более высокую производительность дисковой подсистемы из-за автоматического переключения /sys/block/sdX/queue/scheduler из режима [mq-deadline] в режим [none]. отдельный раздел, размером 8 мегабайт, кстати, ZFS создает при использовании диска в режиме Whole Disk. возможно что именно для этих целей - чтобы была возможность проводить тесты скорости чтения и записи.

Я посмотрю как ты будешь тестировать диск на чтение\запись для проверки его деградации когда у тебя нет отдельного раздела для этого мне удобнее благодаря использованию Whole Disk иметь возможность менять сбойный диск одной командой и удобнее иметь более высокую производительность дисковой подсистемы из-за автоматического переключения /sys/block/sdX/queue/scheduler из режима [mq-deadline] в режим [none]. отдельный раздел, размером 8 мегабайт, кстати, ZFS создает при использовании диска в режиме Whole Disk. возможно что именно для этих целей - чтобы была возможность проводить тесты скорости чтения и записи.

Я посмотрю как ты будешь тестировать диск на чтение\запись для проверки его деградации когда у тебя нет отдельного раздела для этого мне удобнее благодаря использованию Whole Disk иметь возможность менять сбойный диск одной командой и удобнее иметь более высокую производительность дисковой подсистемы из-за автоматического переключения /sys/block/sdX/queue/scheduler из режима [mq-deadline] в режим [none]. отдельный раздел, размером 8 мегабайт, кстати, ZFS создает при использовании диска в режиме Whole Disk. возможно что именно для этих целей - чтобы была возможность проводить тесты скорости чтения и записи.

zfs создаёт раздел чтобы (может быть если повезет) при замене диска на другой с такими же маркетинговыми терабайтами на нём (если очень повезет) можноо было бы сектор-в-сектор по размеру такой же основной раздел получить.

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

Не совсем, эти 8МБ это наследие SUN

А конкретнее? Что за заморочки были у санок?

ну если это openzfs, то по причине старого костыля на диске будет доп раздел в 8МБ, можно просто нарезать партицию на новом диске руками и её подать

Вопрос на миллион, но я выше в чате тестировал, ZFS способен зацепить диск который меньше вплоть до 10 или 20МБ

В смысле новым куском к миррору или раидзу?

То есть для 10ГБ дисков у меня получилось, что я могу +-512МБ делать Исходный диск 10ГБ или 10737418240

В целом же -- эти пляски с "отдавайте весь диск, у нас крутой шедулер" как мне кажется в 2024 имеют мало смысла уже

Не понимаю, как whole диск связан с тем что ранее вы писали? Что gpt таблицу ZFS сам создает для диска? Для меня whole значит без gpt таблицы

почему не имеют смысла? если есть два шедулера - тот который встроен в ZFS и тот который встроен в Linux - не будут ли они друг другу мешать? когда ZFS построит по его мнению наиболее оптимальную последовательность операций, а Linux начнет переупорядочивать по своему? имеют мало смысла для NVMe/SSD, а для обычных HDD - смысл наверное все-таки еще есть.

а можно свои 5 копеек спрошу?) у меня при выводе шедулера идет вот такой вывод для дисков: root@pve:~# cat /sys/block/sdc/queue/scheduler none [mq-deadline] в итоге он какой шедулер пользует, none или дедлайн?) диски zfs отданы именно дисками

Дедлайн. Когда-то, где-то в доках видел, что нужно заменить на none вручную

вот блин🙈 16 дисков править)

Если выделить Whole Disk для ZFS, то в таком случае ZFS самостоятельно создает на диске gpt и разделы.

да ничего)

если не ошибаюсь, то изначально в solaris диски не имели разделов и отдавались без разделов в zfs. Если я правильно понял, то в Linux без разделов не получится работать zfs?

тут даже я ахуел

тут даже я ахуел

^

Это потому, что статья старая

а 8 мб для тестировия непригодны никак ваще, на порядки меньше размеров кешей в дисках

а сколько имеет смысл создавать раздел для тестирования? если в диске встроенный cache, например, размером 512 мегабайт. и зачем этот раздел для тестирования создавать, неужели файловая система ZFS сама не сможет обнаружить сбойный и глючный диск, который [очень] медленно работает? часто ли встречаются такие ситуации, что операции чтения работают максимально быстро, а операции записи очень сильно тормозят? насколько я понимаю, если тормозит запись, то будет тормозить тогда и чтение, а чтобы протестировать скорость чтения с диска - для этого наличие какого-то отдельного раздела не нужно, потому что операция чтения не является деструктивной. я еще не встречал ситуаций, когда чтение работает быстро, а операция записи очень сильно тормозит. обычно бывает наоборот - что именно чтение с какой-то обрасти диска тормозит очень сильно, а запись в другую область диска может работать и нормально при этом.