parallel mounting for ZFS filesystem

Jurij Ivliev написал(а) к All в May 19 18:38:59 по местному времени:

From: Jurij Ivliev <ii@any.com.ru>

Нi, All!

В stable/11 из ZoL прилетело очередное счастье в виде r346690:
MFC r344569, r344618, r344621 (by bapt):
r344569:
Implement parallel mounting for ZFS filesystem
...
r344618:
Fix regression introduced in r344569
...
r344621:
Fix a regression introduced in r344569
...

В результате после загрузки системы при наличии таких датасетов:
$ zfs get -r mountpoint,canmount rpool/home
NAME PROPERTY VALUE SOURCE
rpool/home mountpoint /home received
rpool/home canmount on default
rpool/home/user mountpoint /home/user inherited from rpool/home
rpool/home/user canmount on default
$ zfs get -r mountpoint,canmount dpool/home
NAME PROPERTY VALUE SOURCE
dpool/home mountpoint /home local
dpool/home canmount off local
dpool/home/user mountpoint /home/user inherited from dpool/home
dpool/home/user canmount off local
dpool/home/user/data mountpoint /home/user/data inherited from dpool/home
dpool/home/user/data canmount on default
имеем следующее:
df говорит, что rpool/home, rpool/home/user и dpool/home/user/data
смонтированы как им и положено в /home, /home/user и /home/user/data
и именно в такой последовательности.
df /home говорит, что это rpool/home.
df /home/user говорит, что это также rpool/home, который смонтирован
в /home.
df /home/user/data говорит, что это dpool/home/user/data.
ls /home/user показывает что там есть только каталог data.
Если руками отмонтировать /home/user/data и /home/user, то в /home
остаётся каталог user/data.
Если после этого удалить /home/user и последовательно смонтировать
rpool/home/user и dpool/home/user/data, то всё становится на свои места.

В stable/12 тот же MFC был более месяца назад (r345578 | bapt | 2019-03-27
17:51:03 +0300). Если у кого-то есть возможность проверить поведение
stable/12 после r345578 на схожих датасетах дайте знать, plz, как оно -
перед тем, как засылать PR хочется понять: это кривой MFC в stable/11
или оно by design такое.

И да, если я правильно понял diff -r r346685:r346690, это кю не отключается.
--- ifmail v.2.15dev5.4

Eugene Grosbein написал(а) к Jurij Ivliev в May 19 00:37:45 по местному времени:

05 мая 2019, воскресенье, в 16:38 NOVT, Jurij Ivliev написал(а):

JI> И да, если я правильно понял diff -r r346685:r346690, это кю не отключается.

Всё там отключается. Выставляешь mountpoint=legacy нужным fs
и прописываешь нужный тебе порядок монтирования в /etc/fstab,
как у меня:

z/src /usr/src zfs rw,noauto 0 0
z/obj /usr/obj zfs rw,noauto 0 0
z/ports /usr/ports zfs rw,noauto 0 0

Только у тебя будет без noauto.
Не конфликтующие по путям монтирования fs можешь оставить
вне fstab.

Eugene
--- slrn/1.0.3 (FreeBSD)

Jurij Ivliev написал(а) к Eugene Grosbein в May 19 20:20:02 по местному времени:

From: Jurij Ivliev <ii@any.com.ru>

On Mon, 06 May 2019 00:37:45 +0300,
Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:
JI>> И да, если я правильно понял diff -r r346685:r346690, это кю не
JI>> отключается.
EG> Всё там отключается. Выставляешь mountpoint=legacy нужным fs
EG> и прописываешь нужный тебе порядок монтирования в /etc/fstab,
Не, это совсем не то и не там.

EG> Не конфликтующие по путям монтирования fs можешь оставить
EG> вне fstab.
Про "конфликтующие по путям монтирования fs" - не понял.
Насколько я помню установление правильного порядка автоматического
монтирования датасетов - заявленная фича ZFS. И до сих пор (ещё со
времён появления ZFS в opensolaris) оно всегда работало правильно.
Да и по выводу df в моём случае видно, что монтирование шло (ну как
минимум запускалось) в правильном порядке. Но вот то, что получилось
в результате этому порядку как-то не соответствует.
--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Jurij Ivliev в May 19 20:38:04 по местному времени:

Нello Jurij!

05 May 19, Jurij Ivliev writes to All:

JI> В stable/12 тот же MFC был более месяца назад (r345578 | bapt | 2019-03-27
JI> 17:51:03 +0300). Если у кого-то есть возможность проверить поведение
JI> stable/12 после r345578 на схожих датасетах дайте знать, plz, как оно -
JI> перед тем, как засылать PR хочется понять: это кривой MFC в stable/11
JI> или оно by design такое.

я нихера не понял что конкретно надо проверять

у меня на помледнем 12-stable оно выглядит в моем случае так:

zroot 182G 34.7G 2.21G legacy
zroot/tmp 2.75G 34.7G 2.75G /tmp
zroot/usr 162G 34.7G 1.59G /usr
zroot/usr/home 145G 34.7G 145G /usr/home
zroot/usr/local 6.77G 34.7G 6.53G /usr/local
zroot/usr/local/pgsql 243M 34.7G 243M /usr/local/pgsql
zroot/usr/ports 6.57G 34.7G 771M /usr/ports
zroot/usr/ports/distfiles 5.82G 34.7G 5.82G /usr/ports/distfiles
zroot/usr/ports/packages 26K 34.7G 26K /usr/ports/packages
zroot/usr/src 1.99G 34.7G 1.99G /usr/src
zroot/var 14.3G 34.7G 12.7G /var
zroot/var/crash 23.5K 34.7G 23.5K /var/crash
zroot/var/db 1.53G 34.7G 1.51G /var/db
zroot/var/db/pkg 24.1M 34.7G 24.1M /var/db/pkg
zroot/var/log 2.17M 34.7G 2.17M /var/log
zroot/var/mail 2.07M 34.7G 2.07M /var/mail
zroot/var/run 53.5K 34.7G 53.5K /var/run
zroot/var/tmp 101M 34.7G 101M /var/tmp

ничего специального не делал

# df -h /usr/ports/distfiles /usr/ports /usr/ports/packages /usr/local/pgsql
Filesystem Size Used Avail Capacity Mounted on
zroot/usr/ports/distfiles 40G 5.8G 35G 14% /usr/ports/distfiles
zroot/usr/ports 35G 771M 35G 2% /usr/ports
zroot/usr/ports/packages 35G 26K 35G 0% /usr/ports/packages
zroot/usr/local/pgsql 35G 243M 35G 1% /usr/local/pgsql


... А вы и ухом не моргнули!
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Eugene Grosbein написал(а) к Jurij Ivliev в May 19 01:41:45 по местному времени:

05 мая 2019, воскресенье, в 18:20 NOVT, Jurij Ivliev написал(а):

JI> Про "конфликтующие по путям монтирования fs" - не понял.
JI> Насколько я помню установление правильного порядка автоматического
JI> монтирования датасетов - заявленная фича ZFS. И до сих пор (ещё со
JI> времён появления ZFS в opensolaris) оно всегда работало правильно.

Я не вникал, но если это действительно описано в документации
и это сломали - сделай PR, откатят.

JI> Да и по выводу df в моём случае видно, что монтирование шло (ну как
JI> минимум запускалось) в правильном порядке.

А может быть, тебе просто везло и на самом деле такой гарантии
никто не давал?

И с чего бы монтирование по fstab (официально поддерживаемое)
было "не то и не так"? Оно есть, оно работает.

Eugene
--
Enter old password: xxx
Enter new password: yyy
Confirm password: подтверждаю
--- slrn/1.0.3 (FreeBSD)

Eugene Grosbein написал(а) к Slawa Olhovchenkov в May 19 02:17:07 по местному времени:

05 мая 2019, воскресенье, в 18:38 NOVT, Slawa Olhovchenkov написал(а):

SO> я нихера не понял что конкретно надо проверять

У него два разных пула монтируются вперемешку
один внутрь точек монтирования на другом.

Eugene
--- slrn/1.0.3 (FreeBSD)

Jurij Ivliev написал(а) к Eugene Grosbein в May 19 21:39:35 по местному времени:

From: Jurij Ivliev <ii@any.com.ru>

Нi, Eugene!

On Mon, 06 May 2019 01:41:45 +0300,
Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:
JI>> Да и по выводу df в моём случае видно, что монтирование шло (ну как
JI>> минимум запускалось) в правильном порядке.
EG> А может быть, тебе просто везло и на самом деле такой гарантии
EG> никто не давал?
Ну тогда я офигенно (почти 10 лет!) везучий :)
А если серьёзно, то порядок, в котором fs начинают монтироваться,
вроде бы не поменялся. И если бы можно было как-то "отключить" эту
"параллельность", то всё бы скорее всего смонтировалось правильно.
Есть подозрение, что там где-то гонка.

EG> И с чего бы монтирование по fstab (официально поддерживаемое)
EG> было "не то и не так"? Оно есть, оно работает.
Да безусловно. Только это совсем не про то.
--- ifmail v.2.15dev5.4

Jurij Ivliev написал(а) к Slawa Olhovchenkov в May 19 21:48:06 по местному времени:

From: Jurij Ivliev <ii@any.com.ru>

Нi, Slawa!

On Sun, 05 May 2019 20:38:04 +0300,
Slawa Olhovchenkov <Slawa.Olhovchenkov@f500.n5030.z2.fidonet.org> wrote:
JI>> В stable/12 тот же MFC был более месяца назад (r345578 | bapt | 2019-03-27
JI>> 17:51:03 +0300). Если у кого-то есть возможность проверить поведение
JI>> stable/12 после r345578 на схожих датасетах дайте знать, plz, как оно -
JI>> перед тем, как засылать PR хочется понять: это кривой MFC в stable/11
JI>> или оно by design такое.
SO> я нихера не понял что конкретно надо проверять
SO> у меня на помледнем 12-stable оно выглядит в моем случае так:
SO> zroot 182G 34.7G 2.21G legacy
SO> zroot/tmp 2.75G 34.7G 2.75G /tmp
SO> zroot/usr 162G 34.7G 1.59G /usr
SO> zroot/usr/home 145G 34.7G 145G /usr/home
Если я правильно понял, то у Тебя только один zpool. Тогда это не мой случай.
В пределах одного пула оно вроде бы не ломается.

У меня есть два пула: rpool и dpool. На rpool есть rpool/home, который
монтируется в /home и некоторое количество rpool/home/<user> (mountpoint
которых наследуется и монтируются они, соответственно, как /home/<user>).
На dpool структура аналогичная с тем только отличием, что для dpool/home
и dpool/home/<user> canmount выставлено в off, а внутри dpool/home/<user>
понасоздано всяких датасетов с canmount=on и унаследованными mountpoint,
которые монтируются, соответственно, внутрь /home/<user>/.

После r346690 на stable/11 автомонтирование в такой конфигурации даёт
неправильный результат.
Хотелось бы узнать как в той же позе ведёт себя stable/12 после r345578
(у меня сейчас stable/12 нет).
--- ifmail v.2.15dev5.4

Slawa Olhovchenkov написал(а) к Jurij Ivliev в May 19 21:58:18 по местному времени:

Нello Jurij!

05 May 19, Jurij Ivliev writes to Slawa Olhovchenkov:

JI>>> В stable/12 тот же MFC был более месяца назад (r345578 | bapt |
JI>>> 2019-03-27
JI>>> 17:51:03 +0300). Если у кого-то есть возможность проверить поведение
JI>>> stable/12 после r345578 на схожих датасетах дайте знать, plz, как оно
JI>>> - перед тем, как засылать PR хочется понять: это кривой MFC в
JI>>> stable/11 или оно by design такое.
SO>> я нихера не понял что конкретно надо проверять
SO>> у меня на помледнем 12-stable оно выглядит в моем случае так:
SO>> zroot 182G 34.7G 2.21G legacy
SO>> zroot/tmp 2.75G 34.7G 2.75G /tmp
SO>> zroot/usr 162G 34.7G 1.59G /usr
SO>> zroot/usr/home 145G 34.7G 145G /usr/home
JI> Если я правильно понял, то у Тебя только один zpool. Тогда это не мой
JI> случай. В пределах одного пула оно вроде бы не ломается.

JI> У меня есть два пула: rpool и dpool. На rpool есть rpool/home, который
JI> монтируется в /home и некоторое количество rpool/home/<user> (mountpoint
JI> которых наследуется и монтируются они, соответственно, как /home/<user>).
JI> На dpool структура аналогичная с тем только отличием, что для dpool/home
JI> и dpool/home/<user> canmount выставлено в off, а внутри dpool/home/<user>
JI> понасоздано всяких датасетов с canmount=on и унаследованными mountpoint,
JI> которые монтируются, соответственно, внутрь /home/<user>/.

есть у меня с двумя пулами и перекрестным маунтом, но там еще до паралельного маунта.

... Не все ври, что знаешь.
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Alex Korchmar написал(а) к Eugene Grosbein в May 19 23:11:38 по местному времени:

From: Alex Korchmar <noreply@linux.e-moe.ru>

Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:

EG> Всё там отключается. Выставляешь mountpoint=legacy нужным fs
"главное - ничего не чинить!" (c)

> Alex

--- ifmail v.2.15dev5.4