#21
|
|||
|
|||
Re: parallel mounting for ZFS filesystem
Jurij Ivliev написал(а) к Slawa Olhovchenkov в May 19 15:00:39 по местному времени:
From: Jurij Ivliev <ii@any.com.ru> Нi, Slawa! On Mon, 06 May 2019 14:16:20 +0300, Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote: JI>> А вот код, который отвечает за порядок монтирования, имеется. JI>> И до сих пор работает исправно. JI>> cddl/contrib/opensolaris/lib/libzfs/common/libzfs_mount.c, функция JI>> static int mountpoint_cmp(void const a, void const b); JI>> используется для сравнения в qsort по списку датасетов, кандидатов JI>> на монтирование. SO> мне лень отматывать и смотреть что конкретно у тебя, но если встречается SO> ситуация типа SO> pool1/a => X/a SO> pool1/a/b/c => X/a/b/c SO> pool2/a SO> pool2/a/b => X/a/b то по логике, заложенной в mountpoint_cmp(), получается такой порядок: pool1/a => X/a pool2/a pool2/a/b => X/a/b pool1/a/b/c => X/a/b/c (предполагается, что для pool2/a установлен mountpoint=X/a и canmount=off). То есть при однопотоке всё смонтируется как ожидается (если я правильно понял ожидания). SO> то вообще говоря результат представляется неопределенным и даже в случае SO> однопоточного монтирования зависящим от порядка монтирования самих пулов SO> pool1/pool2 и pool2/pool1 дадут разные результаты. Вот тут не понял. Что такое "монтирования самих пулов"? Насколько я понимаю открытие пулов и монтирование датасетов - последовательные действия. То есть сначала подключаются все известные пулы, а затем с них скопом монтируется всё, что должно смонтироваться. --- ifmail v.2.15dev5.4 |
#22
|
|||
|
|||
parallel mounting for ZFS filesystem
Slawa Olhovchenkov написал(а) к Jurij Ivliev в May 19 15:43:26 по местному времени:
Нello Jurij! 06 May 19, Jurij Ivliev writes to Slawa Olhovchenkov: JI>>> А вот код, который отвечает за порядок монтирования, имеется. JI>>> И до сих пор работает исправно. JI>>> cddl/contrib/opensolaris/lib/libzfs/common/libzfs_mount.c, функция JI>>> static int mountpoint_cmp(void const a, void const b); JI>>> используется для сравнения в qsort по списку датасетов, кандидатов JI>>> на монтирование. SO>> мне лень отматывать и смотреть что конкретно у тебя, но если SO>> встречается ситуация типа pool1/a => X/a pool1/a/b/c => X/a/b/c SO>> pool2/a pool2/a/b => X/a/b JI> то по логике, заложенной в mountpoint_cmp(), получается такой порядок: JI> pool1/a => X/a JI> pool2/a JI> pool2/a/b => X/a/b JI> pool1/a/b/c => X/a/b/c JI> (предполагается, что для pool2/a установлен mountpoint=X/a и canmount=off). JI> То есть при однопотоке всё смонтируется как ожидается (если я правильно JI> понял ожидания). SO>> то вообще говоря результат представляется неопределенным и даже в SO>> случае однопоточного монтирования зависящим от порядка монтирования SO>> самих пулов pool1/pool2 и pool2/pool1 дадут разные результаты. JI> Вот тут не понял. Что такое "монтирования самих пулов"? JI> Насколько я понимаю открытие пулов и монтирование датасетов - JI> последовательные действия. То есть сначала подключаются все известные пулы, JI> а затем с них скопом монтируется всё, что должно смонтироваться. у меня почему-то другое мнение. и как бы zpool import сразу приводит к монтированию всего что там есть, если дополнительных флагов не заданно. ... Поздpавляем! Вы пpошли Windows! Начать новую игpу? --- GoldED+/BSD 1.1.5-b20110223-b20110223 |
#23
|
|||
|
|||
Re: parallel mounting for ZFS filesystem
Eugene Grosbein написал(а) к Jurij Ivliev в May 19 21:36:32 по местному времени:
06 мая 2019, понедельник, в 13:00 NOVT, Jurij Ivliev написал(а): SO>> то вообще говоря результат представляется неопределенным и даже в случае SO>> однопоточного монтирования зависящим от порядка монтирования самих пулов SO>> pool1/pool2 и pool2/pool1 дадут разные результаты. JI> Вот тут не понял. Что такое "монтирования самих пулов"? JI> Насколько я понимаю открытие пулов и монтирование датасетов - последовательные JI> действия. То есть сначала подключаются все известные пулы, а затем JI> с них скопом монтируется всё, что должно смонтироваться. Вы только не смешивайте явный вызов zpool import и автоподключение пулов ядром при загрузке, это не одно и то же. Когда ядерная zfs при загрузке получает возможность поискать пулы в девайсах, которые нанюхал ему GEOM, то пулы, конечно, подключаются в соответствие с zpool.cache, но ничего автоматом с них не монтируется сверх рута. Монтирует явная команда "zfs mount -a" из /etc/rc.d/zfs Например, если имеются зашифрованные при помощи GELI диски с компонентами пула, так что при загрузке пул недоступен, и после загрузки сделать дискам geli attach и далее спровоцировать ZFS на обнюхивание новых GEOM запуском zpool list, то через несколько долей секунды ZFS подключит вновь появившийся пул, но ничего не смонтирует с него. И нужна будет дополнительная команда zfs mount -a, только тогда всё смонтируется. Eugene --- slrn/1.0.3 (FreeBSD) |
#24
|
|||
|
|||
Re: parallel mounting for ZFS filesystem
Eugene Grosbein написал(а) к Eugene Grosbein в May 19 21:55:53 по местному времени:
06 мая 2019, понедельник, в 20:36 NOVT, Eugene Grosbein написал(а): EG> Например, если имеются зашифрованные при помощи GELI EG> диски с компонентами пула, так что при загрузке пул недоступен, EG> и после загрузки сделать дискам geli attach и далее спровоцировать EG> ZFS на обнюхивание новых GEOM запуском zpool list, то через EG> несколько долей секунды ZFS подключит вновь появившийся пул, EG> но ничего не смонтирует с него. И нужна будет дополнительная EG> команда zfs mount -a, только тогда всё смонтируется. Тут кстати есть одна фишка. Так как практически невозможно гарантировать, что geli подключит все шифроконтейнеры одновременно, при использовании RAIDZ/RAIDZ2 вполне возможна ситуация, когда ядерная часть ZFS увидит все компоненты пула, кроме одного или двух и подключит пул как деградированный, а как только появится последний компонент - начнёт восстановление пула на "опоздавший" диск, что неприятно. Если такой пул только один (то есть, корень не на ZFS), то можно подгружать zfs.ko уже после всех geli attach. А для ZFS-on-root нужно в /boot/loader.conf выставить vfs.zfs.maxmissing_tvdscachefile=0 вместо дефолта 2, и тогда ZFS подключит RAIDZ[2] только когда GELI подключит все шифроконтейнеры. При физической замене диска из-за умирания придётся временно увеличивать vfs.zfs.maxmissing_tvdscachefile обратно, чтобы подключить пул как деградировавший. Eugene -- http://grosbeyn.moikrug.ru/ --- slrn/1.0.3 (FreeBSD) |
#25
|
|||
|
|||
Re: parallel mounting for ZFS filesystem
Jurij Ivliev написал(а) к Slawa Olhovchenkov в May 19 18:53:45 по местному времени:
From: Jurij Ivliev <ii@any.com.ru> Нi, Slawa! On Mon, 06 May 2019 15:43:26 +0300, Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote: JI>> Вот тут не понял. Что такое "монтирования самих пулов"? JI>> Насколько я понимаю открытие пулов и монтирование датасетов - JI>> последовательные действия. То есть сначала подключаются все JI>> известные пулы, а затем с них скопом монтируется всё, что JI>> должно смонтироваться. SO> у меня почему-то другое мнение. и как бы zpool import сразу приводит к SO> монтированию всего что там есть, если дополнительных флагов не заданно. Ну zpool import - всё-таки другое. И монтирование всего, что есть в пуле (если не было сказано "-N") - это не какая-то магия, а явный вызов zpoolenabledatasets() после успешного импорта. zpoolenable_datasets() - обёртка над zfs_iterfilesystems() (создает список файловых систем) и zfsforeachmountpoint() (сортирует и монтирует/шарит их). zfs mount -a и zfs share -a дёргают, в конечном итоге, ту же пару функций, только zfsiterfilesystems() зовётся не один раз, а для каждого доступного пула, в результате чего в список попадают все имеющиеся датасеты. Во FreeBSD, при загрузке системы, zfs mount -a зовётся из /etc/rc.d/zfs. На момент исполнения этого скрипта все пулы, отмеченные в /boot/zfs/zpool.cache и доступные при старте ядра уже подключены им. Так что для zfsiterfilesystems() будет доступен весь набор файловых систем во всех пулах. --- ifmail v.2.15dev5.4 |