Можете по чату поискать

Где люди приходят, что ZFS УЖЕ УБИЛ диск, а Smart чистый

В рамках ZFS

Где люди приходят, что ZFS УЖЕ УБИЛ диск, а Smart чистый

Убил тоже большими нужно было😁

К моменту как ZFS скажет - хуйня этот диск - он уже будет failed

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

что интересно. для нвме диска он выставил none

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

Не всегда.

что интересно. для нвме диска он выставил none

Да, так и есть. Я потому не заморачиваюсь с этой настройкой.

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

А ещё читаться могут нули, а не реальные данные

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

а можно свои 5 копеек спрошу?) у меня при выводе шедулера идет вот такой вывод для дисков: root@pve:~# cat /sys/block/sdc/queue/scheduler none [mq-deadline] в итоге он какой шедулер пользует, none или дедлайн?) диски zfs отданы именно дисками судя по выводу - активен [mq-deadline]. тогда я не понимаю вообще, как будет лучше и почему ZFS не переключает в [none] для дисков в режиме Whole Disk. Если самостоятельно ZFS этого не делает - не переключает с [mq-deadline] в [none] значит на то есть какие-то причины? разве что когда Whole Disk, то ZFS автоматически включает Write Cache и именно это и повышает производительность. и более удобно менять сбойный диск через zpool replace. значит ZFS не трогает /sys/block/sdX/queue/scheduler и не переключает из [mq-deadline] в [none] для HDD а для NVMe / SSD он там изначально стоит в [none], даже если на сервере нет ZFS. возможно и не имеет смысла переключать /sys/block/sdX/queue/scheduler из [mq-deadline] в [none] для жестких дисков. hxxps : // serverfault . com /a/1093780 People claim you need to use whole disks to get disk write cache advantages, but that's not true. What is true is that ZFS will try to enable the disk write cache for you if you give it the whole disk. However, even if you just give it a single partition, nobody stops you from enabling the disk write cache yourself, in which case ZFS will detect that and honor it exactly the same was as if it had enabled the cache itself. So it's not a requirement to use whole disks getting write cache advantages, it only saves you the work to enable disk write cache yourself.

а можно свои 5 копеек спрошу?) у меня при выводе шедулера идет вот такой вывод для дисков: root@pve:~# cat /sys/block/sdc/queue/scheduler none [mq-deadline] в итоге он какой шедулер пользует, none или дедлайн?) диски zfs отданы именно дисками судя по выводу - активен [mq-deadline]. тогда я не понимаю вообще, как будет лучше и почему ZFS не переключает в [none] для дисков в режиме Whole Disk. Если самостоятельно ZFS этого не делает - не переключает с [mq-deadline] в [none] значит на то есть какие-то причины? разве что когда Whole Disk, то ZFS автоматически включает Write Cache и именно это и повышает производительность. и более удобно менять сбойный диск через zpool replace. значит ZFS не трогает /sys/block/sdX/queue/scheduler и не переключает из [mq-deadline] в [none] для HDD а для NVMe / SSD он там изначально стоит в [none], даже если на сервере нет ZFS. возможно и не имеет смысла переключать /sys/block/sdX/queue/scheduler из [mq-deadline] в [none] для жестких дисков. hxxps : // serverfault . com /a/1093780 People claim you need to use whole disks to get disk write cache advantages, but that's not true. What is true is that ZFS will try to enable the disk write cache for you if you give it the whole disk. However, even if you just give it a single partition, nobody stops you from enabling the disk write cache yourself, in which case ZFS will detect that and honor it exactly the same was as if it had enabled the cache itself. So it's not a requirement to use whole disks getting write cache advantages, it only saves you the work to enable disk write cache yourself.

А причем тут он?

а можно свои 5 копеек спрошу?) у меня при выводе шедулера идет вот такой вывод для дисков: root@pve:~# cat /sys/block/sdc/queue/scheduler none [mq-deadline] в итоге он какой шедулер пользует, none или дедлайн?) диски zfs отданы именно дисками судя по выводу - активен [mq-deadline]. тогда я не понимаю вообще, как будет лучше и почему ZFS не переключает в [none] для дисков в режиме Whole Disk. Если самостоятельно ZFS этого не делает - не переключает с [mq-deadline] в [none] значит на то есть какие-то причины? разве что когда Whole Disk, то ZFS автоматически включает Write Cache и именно это и повышает производительность. и более удобно менять сбойный диск через zpool replace. значит ZFS не трогает /sys/block/sdX/queue/scheduler и не переключает из [mq-deadline] в [none] для HDD а для NVMe / SSD он там изначально стоит в [none], даже если на сервере нет ZFS. возможно и не имеет смысла переключать /sys/block/sdX/queue/scheduler из [mq-deadline] в [none] для жестких дисков. hxxps : // serverfault . com /a/1093780 People claim you need to use whole disks to get disk write cache advantages, but that's not true. What is true is that ZFS will try to enable the disk write cache for you if you give it the whole disk. However, even if you just give it a single partition, nobody stops you from enabling the disk write cache yourself, in which case ZFS will detect that and honor it exactly the same was as if it had enabled the cache itself. So it's not a requirement to use whole disks getting write cache advantages, it only saves you the work to enable disk write cache yourself.

в моем случае у меня собранный массив из двух слайсов draid2 по 6 дисков каждый, но точно помню что именно диски отдавал по disk-id

а можно свои 5 копеек спрошу?) у меня при выводе шедулера идет вот такой вывод для дисков: root@pve:~# cat /sys/block/sdc/queue/scheduler none [mq-deadline] в итоге он какой шедулер пользует, none или дедлайн?) диски zfs отданы именно дисками судя по выводу - активен [mq-deadline]. тогда я не понимаю вообще, как будет лучше и почему ZFS не переключает в [none] для дисков в режиме Whole Disk. Если самостоятельно ZFS этого не делает - не переключает с [mq-deadline] в [none] значит на то есть какие-то причины? разве что когда Whole Disk, то ZFS автоматически включает Write Cache и именно это и повышает производительность. и более удобно менять сбойный диск через zpool replace. значит ZFS не трогает /sys/block/sdX/queue/scheduler и не переключает из [mq-deadline] в [none] для HDD а для NVMe / SSD он там изначально стоит в [none], даже если на сервере нет ZFS. возможно и не имеет смысла переключать /sys/block/sdX/queue/scheduler из [mq-deadline] в [none] для жестких дисков. hxxps : // serverfault . com /a/1093780 People claim you need to use whole disks to get disk write cache advantages, but that's not true. What is true is that ZFS will try to enable the disk write cache for you if you give it the whole disk. However, even if you just give it a single partition, nobody stops you from enabling the disk write cache yourself, in which case ZFS will detect that and honor it exactly the same was as if it had enabled the cache itself. So it's not a requirement to use whole disks getting write cache advantages, it only saves you the work to enable disk write cache yourself.

как по ссылке пройти ниасилил

а можно свои 5 копеек спрошу?) у меня при выводе шедулера идет вот такой вывод для дисков: root@pve:~# cat /sys/block/sdc/queue/scheduler none [mq-deadline] в итоге он какой шедулер пользует, none или дедлайн?) диски zfs отданы именно дисками судя по выводу - активен [mq-deadline]. тогда я не понимаю вообще, как будет лучше и почему ZFS не переключает в [none] для дисков в режиме Whole Disk. Если самостоятельно ZFS этого не делает - не переключает с [mq-deadline] в [none] значит на то есть какие-то причины? разве что когда Whole Disk, то ZFS автоматически включает Write Cache и именно это и повышает производительность. и более удобно менять сбойный диск через zpool replace. значит ZFS не трогает /sys/block/sdX/queue/scheduler и не переключает из [mq-deadline] в [none] для HDD а для NVMe / SSD он там изначально стоит в [none], даже если на сервере нет ZFS. возможно и не имеет смысла переключать /sys/block/sdX/queue/scheduler из [mq-deadline] в [none] для жестких дисков. hxxps : // serverfault . com /a/1093780 People claim you need to use whole disks to get disk write cache advantages, but that's not true. What is true is that ZFS will try to enable the disk write cache for you if you give it the whole disk. However, even if you just give it a single partition, nobody stops you from enabling the disk write cache yourself, in which case ZFS will detect that and honor it exactly the same was as if it had enabled the cache itself. So it's not a requirement to use whole disks getting write cache advantages, it only saves you the work to enable disk write cache yourself.

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

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

опровергнут миф что у зфс свой шыдулер получается?

в моем случае у меня собранный массив из двух слайсов draid2 по 6 дисков каждый, но точно помню что именно диски отдавал по disk-id

Оттого, как вы отдавали диски, не имеет значения. Настройкой планировщика занимается ядро ОС, а не ZFS

Оттого, как вы отдавали диски, не имеет значения. Настройкой планировщика занимается ядро ОС, а не ZFS

а что же нам рассказывали что зфс байпассит осевой шедулер и само шедулит

опровергнут миф что у зфс свой шыдулер получается?

Нет, ZFS, конечно же имеет свой. Просто она не имеет возможности изменять настройки ОС

Оттого, как вы отдавали диски, не имеет значения. Настройкой планировщика занимается ядро ОС, а не ZFS

так это понятно, но по идее ядро прокса должно быть заточено под использование зфс, просто я до этого вообще не задумывался на этот счет)

раньше - для Whole Disk файловая система действительно меняла scheduler на none, до версии 0.8.3, а сейчас она этого уже не делает. hxxps : // openzfs . github . io /openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#zfs-vdev-scheduler zfs_vdev_scheduler Prior to version 0.8.3, when the pool is imported, for whole disk vdevs, the block device I/O scheduler is set to zfs_vdev_scheduler. The most common schedulers are: noop, cfq, bfq, and deadline. In some cases, the scheduler is not changeable using this method. Known schedulers that cannot be changed are: scsi_mq and none. In these cases, the scheduler is unchanged and an error message can be reported to logs. The parameter was disabled in v0.8.3 but left in place to avoid breaking loading of the zfs module if the parameter is specified in modprobe configuration on existing installations. It is recommended that users leave the default scheduler “unless you’re encountering a specific problem, or have clearly measured a performance improvement for your workload,” and if so, to change it via the /sys/block/<device>/queue/scheduler interface and/or udev rule. zfs_vdev_scheduler Default: noop all, but no effect since v0.8.3 hxxps : // github . com /openzfs/zfs/issues/9778#issuecomment-569347505 Would you recommend not touching default scheduler? That's right, these days the default scheduler works well for most common configurations and hardware. Unless you're encountering a specific problem, or have clearly measured a performance improvement for your workload, my recommendation would be to leave the default scheduler. There were suspicions that implicated mq-deadline when the kernel first introduced multiqueue support. However, the upstream kernel appears to have sorted this out and it's no longer and issue with modern kernels.

а что же нам рассказывали что зфс байпассит осевой шедулер и само шедулит

раньше именно так и было в старых версиях ZFS.

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

не только - еще в такой ситуации гораздо удобнее менять сбойный диск на новый, это можно делать одной командой zpool replace без необходимости вручную создавать разделы на новом (чистом) диске. и автоматическое включение Write Cache у HDD, если они отданы ZFS в режиме Whole Disk, а не отдельными разделами.

раньше именно так и было в старых версиях ZFS.

а щяс получается сначала неведомый шедулер зфс потом осевой (который запросто может отменить всё что зфсный настрадал). двойная работа а толку меньше

а щяс получается сначала неведомый шедулер зфс потом осевой (который запросто может отменить всё что зфсный настрадал). двойная работа а толку меньше

скорее всего что тесты не смогут обнаружить разницы, если протестировать производительность файловой системы с включенным /sys/block/sdX/queue/scheduler [mq-deadline] и потом сравнить с /sys/block/sdX/queue/scheduler [none]. а даже если и есть "двойная работа" то на уровне современных процессорных мощностей она будет совершенно не заметна. да и вряд ли системный scheduler будет переупорядочивать обращения к диску, если ZFS scheduler уже поставил дисковые операции в наиболее оптимальном порядке. если тесты показывают, что разница есть - тогда имеет смысл этим заморачиваться и переключать scheduler вручную, как об этом и говорится в документации: It is recommended that users leave the default scheduler “unless you’re encountering a specific problem, or have clearly measured a performance improvement for your workload,” and if so, to change it via the /sys/block/<device>/queue/scheduler interface and/or udev rule.

скорее всего что тесты не смогут обнаружить разницы, если протестировать производительность файловой системы с включенным /sys/block/sdX/queue/scheduler [mq-deadline] и потом сравнить с /sys/block/sdX/queue/scheduler [none]. а даже если и есть "двойная работа" то на уровне современных процессорных мощностей она будет совершенно не заметна. да и вряд ли системный scheduler будет переупорядочивать обращения к диску, если ZFS scheduler уже поставил дисковые операции в наиболее оптимальном порядке. если тесты показывают, что разница есть - тогда имеет смысл этим заморачиваться и переключать scheduler вручную, как об этом и говорится в документации: It is recommended that users leave the default scheduler “unless you’re encountering a specific problem, or have clearly measured a performance improvement for your workload,” and if so, to change it via the /sys/block/<device>/queue/scheduler interface and/or udev rule.

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

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

если б существовал "оптимальный" (всегда и везде) порядок обращений то и выбирать разные щедулеры не приходилось бы. а так - двойная работа даже если ничего не менять. но перед тем как менять - имеет смысл сначала протестировать, будет ли scheduler [mq-deadline] действительно давать меньше IOPS, и меньшую производительность, чем scheduler [none]. и наконец по некоторой инфе зфс лагает сама (т.е. те самые мощности процессоров) на быстрых ссд для SSD / NVMe самой операционной системой I/O scheduler выставлен в [none] и ZFS эту настройку не меняет. кроме того, настройка metaslab_lba_weighting_enabled применяется только тогда, когда /sys/block/sdX/queue/rotational выставлено в 1, а это так только для HDD. А для SSD / NVMe настройка metaslab_lba_weighting_enabled игнорируется, хотя и отображается равной 1, но в действительности - внутри модуля ядра она переключается автоматически в состояние 0=do not use LBA weighting. хотя в параметрах и отображается, что у нее значение 1: # arc_summary | grep metaslab_lba_weighting_enabled metaslab_lba_weighting_enabled 1 - это такой косметический BUG, по крайней мере, в версии zfs 2.1 может быть его уже и поправили в новых версиях zfs 2.2 или zfs 2.3.

для полноты картины - нашел на гитхабе zfs объяснение причины, почему убрали zfs_vdev_scheduler и автоматическое переключение /sys/block/sdX/queue/scheduler в режим [none] для дисков которые в режиме Whole Disk используются лишь только zfs и больше никакими другими файловыми системами не используются. это еще в 2019 году убрали: hxxps : // github . com /openzfs/zfs/commit/f81d5ef686e8198c38caa8622905647667165622 Add warning for zfs_vdev_elevator option removal Originally the zfs_vdev_elevator module option was added as a convenience so the requested elevator would be automatically set on the underlying block devices. At the time this was simple because the kernel provided an API function which did exactly this. This API was then removed in the Linux 4.12 kernel which prompted us to add compatibly code to set the elevator via a usermodehelper. While well intentioned this introduced a bug which could cause a system hang, that issue was subsequently fixed by commit 2a0d418. In order to avoid future bugs in this area, and to simplify the code, this functionality is being deprecated. A console warning has been added to notify any existing consumers and the documentation updated accordingly. This option will remain for the lifetime of the 0.8.x series for compatibility but if planned to be phased out of master. так что вполне может быть и так, что переключение /sys/block/sdX/queue/scheduler в режим [none] действительно даст прирост производительности, но если раньше это делалось автоматически - то теперь это уже надо будет делать вручную. но такое ручное переключение при каждой загрузке сервера может иметь смысл только для HDD, потому что для NVMe / SSD scheduler самой операционной системой Linux изначально выставляется в режим [none]. логично предположить, что на сервере с 8 дисками по 20 TiB каждый, системный scheduler для всех восьми HDD в режиме [mq-deadline] производительности дисковой подсистеме не добавит, потому что в ZFS есть свой собственный I/O scheduler и обращения к диску уже происходят в самом оптимальном порядке, - с точки зрения файловой системы ZFS.

для полноты картины - нашел на гитхабе zfs объяснение причины, почему убрали zfs_vdev_scheduler и автоматическое переключение /sys/block/sdX/queue/scheduler в режим [none] для дисков которые в режиме Whole Disk используются лишь только zfs и больше никакими другими файловыми системами не используются. это еще в 2019 году убрали: hxxps : // github . com /openzfs/zfs/commit/f81d5ef686e8198c38caa8622905647667165622 Add warning for zfs_vdev_elevator option removal Originally the zfs_vdev_elevator module option was added as a convenience so the requested elevator would be automatically set on the underlying block devices. At the time this was simple because the kernel provided an API function which did exactly this. This API was then removed in the Linux 4.12 kernel which prompted us to add compatibly code to set the elevator via a usermodehelper. While well intentioned this introduced a bug which could cause a system hang, that issue was subsequently fixed by commit 2a0d418. In order to avoid future bugs in this area, and to simplify the code, this functionality is being deprecated. A console warning has been added to notify any existing consumers and the documentation updated accordingly. This option will remain for the lifetime of the 0.8.x series for compatibility but if planned to be phased out of master. так что вполне может быть и так, что переключение /sys/block/sdX/queue/scheduler в режим [none] действительно даст прирост производительности, но если раньше это делалось автоматически - то теперь это уже надо будет делать вручную. но такое ручное переключение при каждой загрузке сервера может иметь смысл только для HDD, потому что для NVMe / SSD scheduler самой операционной системой Linux изначально выставляется в режим [none]. логично предположить, что на сервере с 8 дисками по 20 TiB каждый, системный scheduler для всех восьми HDD в режиме [mq-deadline] производительности дисковой подсистеме не добавит, потому что в ZFS есть свой собственный I/O scheduler и обращения к диску уже происходят в самом оптимальном порядке, - с точки зрения файловой системы ZFS.

как открыть ссылку в телефоне????

как открыть ссылку в телефоне????

https://github.com/openzfs/zfs/commit/f81d5ef686e8198c38caa8622905647667165622 какой-то бот удалял мои сообщения, если находил в них гиперссылку, потому что с момента моего подключения к чату прошло меньше чем 24 часа, поэтому раньше мне приходилось публиковать ссылки в искаженном виде, чтобы он их не видел.

человек обратился с простым вопросом, вы ему за воротник напихали... 1. Создаем пул. Корневой датасет будет смонтирован в корень: /tank zpool create -o ashift=12 -O relatime=off -O atime=off -O compression=zstd -O xattr=sa -O normalization=formD -O acltype=posixacl -f tank /dev/disk/by-id/[чистый диск] 2. копируем данные со второго диска в пул cp /mnt/[каталог для монтирования диска с данными] /tank 3. проверяем, что данные скопировались zpool list zfs list видим, что % изменились, есть какая-то занятость пула ls -l /tank также видим семейные данные 4. форматируем диск с данными 5. добавляем диск к пулу с учетом, что хотим сделать зеркало zpool attach tank /dev/disk/by-id/[диск в пуле] /dev/disk/by-id/[подготовленный диск] 6. проверяем, ждем окончания синхронизации данных watch zpool status

Вчера сделал. Заодно пересобрал пул по полным именам дисков. Все получилось. Благодарю.

У меня теперь следующая делема: Есть у меня SSD на 240Гб, Kingston (модель не помню) и в связи с этим есть задумка либо/либо: 1. Разместить на нём L2ARC. 2. Отдать под гнездовье виртуальных машин virtualbox'а. Сначала думал, что выберу 1 вариант, а виртуальные машины закину на ZFS, но не уверен, что правильно думаю. Хочется и обезопасить виртуальные машины и в тоже время хочется дать им возможность работать шустрее. У кого какие соображения есть на этот счет?

У меня теперь следующая делема: Есть у меня SSD на 240Гб, Kingston (модель не помню) и в связи с этим есть задумка либо/либо: 1. Разместить на нём L2ARC. 2. Отдать под гнездовье виртуальных машин virtualbox'а. Сначала думал, что выберу 1 вариант, а виртуальные машины закину на ZFS, но не уверен, что правильно думаю. Хочется и обезопасить виртуальные машины и в тоже время хочется дать им возможность работать шустрее. У кого какие соображения есть на этот счет?

У меня Intel Optane особо не дал бафа в качестве l2 (()

У меня теперь следующая делема: Есть у меня SSD на 240Гб, Kingston (модель не помню) и в связи с этим есть задумка либо/либо: 1. Разместить на нём L2ARC. 2. Отдать под гнездовье виртуальных машин virtualbox'а. Сначала думал, что выберу 1 вариант, а виртуальные машины закину на ZFS, но не уверен, что правильно думаю. Хочется и обезопасить виртуальные машины и в тоже время хочется дать им возможность работать шустрее. У кого какие соображения есть на этот счет?

Оптаны хороши ежели их под ZIL отдать.

Под кэш смысла нет

Оптаны хороши ежели их под ZIL отдать.

Под ЗИЛ не хватит выносливости и , самое главное , нет защиты по питанию у этой фигни

Под ЗИЛ не хватит выносливости и , самое главное , нет защиты по питанию у этой фигни

Дыг две штуки в зеркале, все дела

А защита по питанию для wal нафиг не нужна

Весь поинт wal - сделать из двух ненадёжных штук одну достаточно надёжную

Дыг две штуки в зеркале, все дела

Хоть 22 Без защиты по питанию нет смысла

Хоть 22 Без защиты по питанию нет смысла

Возможно я не очень понимаю как работает wal. А возможно - вы

Вы же этим девайсом сохраняете данные последних 5 сек транзакций(по умолчанию) в случит потери питания

У меня теперь следующая делема: Есть у меня SSD на 240Гб, Kingston (модель не помню) и в связи с этим есть задумка либо/либо: 1. Разместить на нём L2ARC. 2. Отдать под гнездовье виртуальных машин virtualbox'а. Сначала думал, что выберу 1 вариант, а виртуальные машины закину на ZFS, но не уверен, что правильно думаю. Хочется и обезопасить виртуальные машины и в тоже время хочется дать им возможность работать шустрее. У кого какие соображения есть на этот счет?

не надо на нём ничего делать

Вы же этим девайсом сохраняете данные последних 5 сек транзакций(по умолчанию) в случит потери питания

Потеря данных вообще ортогональна wal и питанию

А защита по питанию для wal нафиг не нужна

что блядь

Если она атомарна - пофиг

что блядь

А в чём тогда его поинт?

ZIL существует ИМЕННО за тем, чтобы из него прочитать данные после пропажи питания

ZIL существует ИМЕННО за тем, чтобы из него прочитать данные после пропажи питания

И это есть в доке))

не надо на нём ничего делать

Что так?

ZIL существует ИМЕННО за тем, чтобы из него прочитать данные после пропажи питания

Если у тебя данные пребались посередине транзакции в wal - ну сорян. Задача wal в том, чтобы ты мог восстановить максимум транзакций, а не вообще всё

Что так?

Он может элементарно сдохнуть

Он может элементарно сдохнуть

Поэтому на рейд его

И потом тебе будет очень весело импортировать систему, а учитывая как ты читаешь доку - тем проще система, тем лучше тебе же будет

Поэтому на рейд его

У него он один

Вы разъеб консистентности с невосстановлением каждой транзации не путайте

Если у тебя данные пребались посередине транзакции в wal - ну сорян. Задача wal в том, чтобы ты мог восстановить максимум транзакций, а не вообще всё

Окей, ты смотришь с ситуации, когда у тебя приклад пишет всегда в sync режиме

А я про ситуацию, когда на пуле sync=always, а прикладу похуй

У него он один

Я и говорю - ничего не делать в его случае

Что так?

Это помойка и для кэша( ибо на случ доступе это бытовое говно просядет до скоростей usb2) и нет защиты по питанию ( для зил)

Если диск один - не нужно на нем делать ничего из arc/zil фигни. Ваш кэп

А когда он отъёбнет в ходе работы - тебе ребутаться, вытаскивать его, и импортировать пул без l2arc через force

Теория вероятностей опять же говорит что в таком сетапе в итоге отвалит раньше

А она - беспощадная скотина

Если очень хочется заюзать его под что-то - поставь туда ОС.

Он может элементарно сдохнуть

Это понятно. Всё рано или поздно... А если на нем в этот момент будет кэш, то разве это убьет пул? Просто производительность упадет ведь, т.к. кэша не станет. Разве не так?

Если очень хочется заюзать его под что-то - поставь туда ОС.

ОС у меня и так на SSD, на другом.

Это понятно. Всё рано или поздно... А если на нем в этот момент будет кэш, то разве это убьет пул? Просто производительность упадет ведь, т.к. кэша не станет. Разве не так?

Кэш на нем говно будет Писал же

Есть у меня SSD на 240Гб, Kingston (модель не помню) и в связи с этим есть задумка либо/либо: 1. Разместить на нём L2ARC. 2. Отдать под гнездовье виртуальных машин virtualbox'а. Сначала думал, что выберу 1 вариант, а виртуальные машины закину на ZFS, но не уверен, что правильно думаю. Хочется и обезопасить виртуальные машины и в тоже время хочется дать им возможность работать шустрее. У кого какие соображения есть на этот счет? Если потеря данных виртуальных машин за какое-то время (например, 1 час или 15 минут) не критична, то можно сделать такой вариант: На HDD - сделать медленное и более защищенное хранилище, zpool tank, на SSD - сделать более быстрое хранилище, например, zpool fast. Виртуальные машины разместить на SSD, на zpool fast И настроить чтобы время от времени на zpool fast создавались snapshot`ы виртуальных машин и через zfs send | zfs recv они копировались на более медленный и более надежный zpool tank. Таким образом будут достигнуты обе цели одновременно: 1. и виртуальные машины будут работать быстро с дисковой подсистемой, потому что будут размещены на SSD 2. данные виртуальных машин будут надежно защищены, максимум что можно потерять - данные внутри виртуальных машин за небольшой промежуток времени. дополнительный бонус в том, что можно сделать sparse volume, так что виртуальный диск виртуальной машины будет по размеру превосходить количество свободного места в zpool, это так называемый thin provisioning. Чтобы свободное место внутри виртуальной машины не занимало физически места на zpool - для виртуальной машины надо включить discard='unmap' и cache='none' - это или через virt-manager или в xml-конфиге вручную для диска, через virsh edit - чтобы KVM делал reclaim свободного места и TRIM/UNMAP из виртуальной машины пропускал дальше, на уровень zfs. Современные линуксы внутри виртуальной машины делают reclaim свободного места или по запросу, через fstrim по крону, или через опцию монтирования файловых систем discrad, лучше совместить оба варианта, чтобы они дополняли друг друга. Виндовс 11 умеет сам делать reclaim свободного места, но это будет происходить только если он будет видеть виртуальный SCSI диск - так что при установке надо будет монтировать и CD-ROM с системой и CD-ROM с драйверами для Windows для KVM - virtio-win.iso от https://github.com/virtio-win/kvm-guest-drivers-windows для диска установка паравиртуализированных SCSI драйверов обязательна, но и все остальные драйвера - также желательно поставить, тогда виртуальная машина будет работать быстрее. Там раньше было два варианта SCSI драйвера - vioscsi и viostor и режим UNMAP в виндовсе работал только с одним из них. Когда виндовс видит диск как thin provisioned - это отображается в утилите дефрагментации, и кроме того - при записи какого-то большого файла на виртуальный диск - через zfs list видно, как zvol величивается в размере, а после того как это файл полностью удалить в виндовсе - через zfs list видно, как виртуальный диск уменьшается в размере. zfs create -s -b 16K -V <размер_диска> <имя_zvol> виртуальные диски лучше создавать с размером блока 16К, чтобы компрессия могла работать. Виндовс 11 работает лучше после метода MASSGRAVE - тогда получается Activated by Digital License (метод HWID) без необходимости что-либо менять в системе и без необходимости устанавливать или запускать дополнительно какие-то активаторы. ======================== По аналогичному алгоритму работает redis - все данные хранит на очень быстром носителе инофрмации - в оперативной памяти, но при этом время от времени делает снимки памяти и сохраняет их на диск - persistend storage, чтобы было откуда восстановиться в случае аварийного завершения работы сервера/программы. здесь аналогично, если использовать этот метод - zpool fast, размещенный на SSD будет выполнять роль быстрого, но не надежного носителя информации, а zpool fank, размещенный на mirror vdev из двух HDD будет выполнять роль более медленного, но более надежного хранителя информации.

таким образом будет одновременно и быстрая работа виртуальных машин, потому что они будут размещены на SSD, и при этом - будет их копия размещена на HDD, чтобы была возможность оттуда восстановиться, когда этот SSD выйдет из строя. недостатки этого варианта - копия виртуальных машин будет храниться в двух местах, на SSD и на HDD, надо будет потратить немного времени чтобы настроить такую репликацию виртуальных дисков с SSD на HDD, и в случае вывода из строя SSD - часть информации будет утеряна, за последние 60, 40, 30, 20, 15, 10 минут - в зависимости от того, как часто будут реплицироваться снапшоты с образами дисков виртуальных машин с SSD на HDD. zfs send имеет смысл делать инкрементальным, чтобы передавались не все блоки, а только те, что изменились по сравнению с предыдущим снапшотом, более старые снапшоты надо будет удалять и на SSD и на HDD, чтобы они не занимали место. заодно это будет еще и бекап для виртуальных машин - если некоторое количество снапшотов (например, создаваемых раз в сути) хранить на HDD.

таким образом будет одновременно и быстрая работа виртуальных машин, потому что они будут размещены на SSD, и при этом - будет их копия размещена на HDD, чтобы была возможность оттуда восстановиться, когда этот SSD выйдет из строя. недостатки этого варианта - копия виртуальных машин будет храниться в двух местах, на SSD и на HDD, надо будет потратить немного времени чтобы настроить такую репликацию виртуальных дисков с SSD на HDD, и в случае вывода из строя SSD - часть информации будет утеряна, за последние 60, 40, 30, 20, 15, 10 минут - в зависимости от того, как часто будут реплицироваться снапшоты с образами дисков виртуальных машин с SSD на HDD. zfs send имеет смысл делать инкрементальным, чтобы передавались не все блоки, а только те, что изменились по сравнению с предыдущим снапшотом, более старые снапшоты надо будет удалять и на SSD и на HDD, чтобы они не занимали место. заодно это будет еще и бекап для виртуальных машин - если некоторое количество снапшотов (например, создаваемых раз в сути) хранить на HDD.

ChatGPT

ОС у меня и так на SSD, на другом.

У меня вопрос ещё был вчера. С чего Вы взяли, что убунту меньше нагрузки даёт, чем прокс?)) В Убунте куча ненужного мусора. Плюс разработчики OpenZFS рекомендуют Дебиан, так как они управляют там всем циклом сборки. А в Убунте уже не раз ломали сборку.

У меня теперь следующая делема: Есть у меня SSD на 240Гб, Kingston (модель не помню) и в связи с этим есть задумка либо/либо: 1. Разместить на нём L2ARC. 2. Отдать под гнездовье виртуальных машин virtualbox'а. Сначала думал, что выберу 1 вариант, а виртуальные машины закину на ZFS, но не уверен, что правильно думаю. Хочется и обезопасить виртуальные машины и в тоже время хочется дать им возможность работать шустрее. У кого какие соображения есть на этот счет?

Ничего особенного в данном случае сделать с одним ссд диском не получится. У меня настроены виртуалки на пул, в котором 2 диска в зеркале hdd 2терабайта. К ним log в mirror 2 nvme диска.

ChatGPT

Очень похоже, что все его посты это chatgpt

Тогда сразу становится понятны некоторые очень странные слова и выводы в его постах

Сперва наспрашивал chatgpt, а потом пошёл спрашивать коммьюнити, а правильно ли гпт насоветовал

кстати, другие боты получше формируют ответ и нужно специальным сервисом проверят "человечность"

У меня вопрос ещё был вчера. С чего Вы взяли, что убунту меньше нагрузки даёт, чем прокс?)) В Убунте куча ненужного мусора. Плюс разработчики OpenZFS рекомендуют Дебиан, так как они управляют там всем циклом сборки. А в Убунте уже не раз ломали сборку.

Здесь вопрос не только в нагрузке которую дает proxmox/Ubuntu, а еще в том, что этот ПК используется как бытовой - для интернет-серфинга, просмотра кино/видео и т.п. И если на него поставить proxmox, то на сколько я понимаю все это придётся делать через ещё одну виртуальную машину. Мне кажется не совсем это будет комфортно...

Здесь вопрос не только в нагрузке которую дает proxmox/Ubuntu, а еще в том, что этот ПК используется как бытовой - для интернет-серфинга, просмотра кино/видео и т.п. И если на него поставить proxmox, то на сколько я понимаю все это придётся делать через ещё одну виртуальную машину. Мне кажется не совсем это будет комфортно...

У прокса под капотом дебиан. Можно спокойно накатить любой x сервер и пользоваться как обычной ОС. Но при этом имея веб интерфейс по управлению хранилищем, контейнерами и ВМ.

Добрый день, помогите! Есть ли способ восстановить данные, если я случайно удалил снапшот и набор данных из пула zfs?

Добрый день, помогите! Есть ли способ восстановить данные, если я случайно удалил снапшот и набор данных из пула zfs?

Да, но рисковано