= Сообщение: 6770 из 10757 ===================================== RU.UNIX.BSD = От : Eugene Grosbein 2:5006/1 19 Mar 18 22:58:11 Кому : Slawa Olhovchenkov 19 Mar 18 22:58:11 Тема : Re: Шифрование FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+2b8597b7 На : area://RU.UNIX.BSD?msgid=2:5030/500+5aafb3c0 = Кодировка сообщения определена как: IBM866 ================================= Ответ: area://RU.UNIX.BSD?msgid=2:5030/500+5aafead1 ============================================================================== 19 марта 2018, понедельник, в 15:48 NOVT, Slawa Olhovchenkov написал(а):
EG>> Hе вижу, чем плохо выделить начало диска в отдельный небольшой EG>> загрузочный пул. Особенно с учетом того, что фичи в загрузчик попадают SO> тем, что нагрузка на диск начинает происходить внезапно.
Hету там нагрузки. Только чтение при загрузки системы, да запись при апгрейдах. /usr можно вообще r/o монтировать, оно низачем не нужно смонтированное r/w.
SO> zfs работая с остаком SO> диска не предполагает, что обращения к другому диску отразятся на этом остатке. SO> синхронизация дисков опят же будет происходить даже с пустым местом,
Это очень небольшая плата за то, что таблица разделов и все загрузчики синхронизируются автоматически, не требуя создания разделов на новом диске. 10 гигабайт начала диска на дешевой материнке ASRock девятилетней давности с контроллером ICH7 (даже не ICH7R), без поддержки AHCI-режима синхронизируются ажно четыре минуты:
Dec 27 19:04:28 eg kernel: GEOM_RAID: Promise: Disk ada1 state changed from NONE to ACTIVE. Dec 27 19:04:28 eg kernel: GEOM_RAID: Promise: Subdisk r0:1-ada1 state changed from NONE to STALE. Dec 27 19:04:28 eg kernel: GEOM_RAID: Promise: Disk ada1 state changed from ACTIVE to ACTIVE. Dec 27 19:04:28 eg kernel: GEOM_RAID: Promise: Subdisk r0:1-ada1 state changed from STALE to RESYNC. Dec 27 19:04:28 eg kernel: GEOM_RAID: Promise: Subdisk r0:1-ada1 rebuild start at 0. Dec 27 19:08:30 eg kernel: GEOM_RAID: Promise: Subdisk r0:1-ada1 rebuild completed.
SO> а zfs в это время будет вообще не живой.
Hормально всё с ним будет - graid это тебе не gmirror, graid умеет синхронизировать сколь угодно плавно:
kern.geom.raid.idle_threshold: Time in microseconds to consider a volume idle. kern.geom.raid.raid1e.rebuild_meta_update: When to update the meta data. kern.geom.raid.raid1e.rebuild_cluster_idle: Number of slabs to do each time we trigger a rebuild cycle kern.geom.raid.raid1e.rebuild_fair_io: Fraction of the I/O bandwidth to use when disk busy for rebuild. kern.geom.raid.raid1e.rebuild_slab_size: Amount of the disk to rebuild each read/write cycle of the rebuild.
И это реально работает - сколь угодно плавное регулирование нагрузки, которую докидывает фоновая синхронизация graid.
EG>> позднее, чем в основной код ZFS (типа checksum=skein недавно) EG>> и на загрузочном пуле включать их не стоит, в то время как на основных EG>> они полезны. SO> да не особо они нужны. да и толку от включения-то? вот есть у меня инсталяция с SO> отдельным tank. там уже лежит 30ТБ. ну включу я там skein и что? да ничего не SO> поменяется.
Я имел в виду включать на новой инсталляции.
SO> да и оверхед на чексумы копеешный (уж я-то задрачиваюсь на замеры).
80% faster than SHA-256 - враньё?
SO> тогда смысла вообще нет. в случае bios там хоть есть шанс что int13 будет SO> переключаться на другой диск, если попало на сбойный сектор.
Смысл в том, что нет ручного переразбиения и необходимости ручной установки загрузчиков при замене диска и нет деградации свопа.
SO>>>>> ну и т.д. EG>>>> Что именно "т.д."? SO>>> да какая разница EG>> Ok, вычеркиваю. SO> короче, я так делал -- ощущения отвратительные.
Я всё ещё не понимаю, откуда ты для *основного* пула вытаскиваешь разницу между gpt-разделами и SINGLE-томами graid, когда в обоих случаях выполняется только пересчёт смещений и передача запросов далее.
Загрузочный пул с рутом и /usr и нулевой нагрузкой на них вообще никому не интересен. Все файловые системы типа /var, /usr/local, /home и т.д. живут не на этом пуле.
Eugene -- Поэты - страшные люди. У них все святое. --- slrn/1.0.2 (FreeBSD) * Origin: RDTC JSC (2:5006/1@fidonet)
