Странное с дисками под zpool-ом

Victor Sudakov написал(а) к All в Apr 18 00:36:28 по местному времени:

Dear All,

Я пока не выяснил, что именно сделали с железом на удалённом сервере, но картина такая: disk devices чем-то накрыло:

# zpool status
pool: zroot
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
diskid/DISK-56K51TNLSp3 ONLINE 0 0 0
diskid/DISK-56K56YGASp3 ONLINE 0 0 0

errors: No known data errors
#

# ls /dev/ada*
/dev/ada0 /dev/ada1
#
# gpart show ada0
gpart: No such geom: ada0.
#

У меня своп был настроен на /dev/ada0p2 и /dev/ada1p2, соответственно после перезагрузки свопа не стало. Как вернуть девайсы, точнее GPT разделы?

PS
"swapon /dev/diskid/DISK-56K51TNLSp2" помог как временная мера, но хотелось бы знать, какой geom накрыл /dev/ada* и почему.



Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Slawa Olhovchenkov написал(а) к Victor Sudakov в Apr 18 21:44:04 по местному времени:

Нello Victor!

15 Apr 18, Victor Sudakov writes to All:

VS> Dear All,

VS> Я пока не выяснил, что именно сделали с железом на удалённом сервере, но
VS> картина такая: disk devices чем-то накрыло:

VS> # zpool status
VS> pool: zroot
VS> state: ONLINE
VS> scan: none requested
VS> config:

VS> NAME STATE READ WRITE CKSUM
VS> zroot ONLINE 0 0 0
VS> mirror-0 ONLINE 0 0 0
VS> diskid/DISK-56K51TNLSp3 ONLINE 0 0 0
VS> diskid/DISK-56K56YGASp3 ONLINE 0 0 0

VS> errors: No known data errors
VS> #

VS> # ls /dev/ada*
VS> /dev/ada0 /dev/ada1
VS> #
VS> # gpart show ada0
VS> gpart: No such geom: ada0.
VS> #

VS> У меня своп был настроен на /dev/ada0p2 и /dev/ada1p2, соответственно после
VS> перезагрузки свопа не стало. Как вернуть девайсы, точнее GPT разделы?

VS> PS
VS> "swapon /dev/diskid/DISK-56K51TNLSp2" помог как временная мера, но хотелось
VS> бы знать, какой geom накрыл /dev/ada* и почему.

kern.geom.label.disk_ident.enable=0
kern.geom.label.gptid.enable="0"


... Винда не пpиходит одна. (c) Microsoft Team
--- GoldED+/BSD 1.1.5-b20110223-b20110223

Eugene Grosbein написал(а) к Victor Sudakov в Apr 18 03:46:21 по местному времени:

14 апр. 2018, суббота, в 22:36 NOVT, Victor Sudakov написал(а):

VS> Я пока не выяснил, что именно сделали с железом на удалённом сервере, но
VS> картина такая: disk devices чем-то накрыло:
VS> # zpool status
VS> pool: zroot
VS> state: ONLINE
VS> scan: none requested
VS> config:
VS> NAME STATE READ WRITE CKSUM
VS> zroot ONLINE 0 0 0
VS> mirror-0 ONLINE 0 0 0
VS> diskid/DISK-56K51TNLSp3 ONLINE 0 0 0
VS> diskid/DISK-56K56YGASp3 ONLINE 0 0 0
VS> errors: No known data errors
VS> #
VS> # ls /dev/ada*
VS> /dev/ada0 /dev/ada1
VS> #
VS> # gpart show ada0
VS> gpart: No such geom: ada0.

gpart show без аргументов подсказал бы тебе правду.

VS> У меня своп был настроен на /dev/ada0p2 и /dev/ada1p2, соответственно после
VS> перезагрузки свопа не стало. Как вернуть девайсы, точнее GPT разделы?

Как уже написал Слава, сказать GEOM_LABEL'у не делать так.
А я бы ещё посоветовал не делать своп на ada[01], а делать на метках:

glabel label swap0 /dev/ada0p2
glabel label swap1 /dev/ada1p2

И своп делать на /dev/label/swap0 и /dev/label/swap1 -
эти имена всегда будут доступны, неважно видится ли GPT
у тебя на ada или на diskid.

VS> "swapon /dev/diskid/DISK-56K51TNLSp2" помог как временная мера, но хотелось бы
VS> знать, какой geom накрыл /dev/ada*

GEOM_LABEL

VS> и почему.

Сложно сказать, не зная, что там у тебя настроено.

Eugene
--
Прекрасны тонко отшлифованная драгоценность; победитель, раненный в бою;
слон во время течки; река, высыхающая зимой; луна на исходе; юная женщина,
изнуренная наслаждением, и даятель, отдавший все нищим. (Дхарма)
--- slrn/1.0.2 (FreeBSD)

Victor Sudakov написал(а) к Slawa Olhovchenkov в Apr 18 12:06:22 по местному времени:

Dear Slawa,

14 Apr 18 21:44, you wrote to me:
VS>> Dear All,

VS>> Я пока не выяснил, что именно сделали с железом на удалённом
VS>> сервере, но картина такая: disk devices чем-то накрыло:

VS>> # zpool status
VS>> pool: zroot
VS>> state: ONLINE
VS>> scan: none requested
VS>> config:

VS>> NAME STATE READ WRITE CKSUM
VS>> zroot ONLINE 0 0 0
VS>> mirror-0 ONLINE 0 0 0
VS>> diskid/DISK-56K51TNLSp3 ONLINE 0 0 0
VS>> diskid/DISK-56K56YGASp3 ONLINE 0 0 0

[dd]

SO> kern.geom.label.disk_ident.enable=0

1. Оно по умолчанию "1" с момента установки системы. Что могло измениться после очередной перезагрузки (совпавшей со сменой железа), что пул пересел на /dev/diskid/* ?

2. Если я это таки напишу в loader.conf, и при следующей перезагрузке /dev/diskid/* не станет, не потеряю ли я данный пул совсем?

Отчего вообще зависит, на каких устройствах ZFS находит устройства с пулом?

SO> kern.geom.label.gptid.enable="0"

А это уже стоит в loader.conf, как я понимаю, с момента установки, его bsdinstall туда написал.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Victor Sudakov написал(а) к Eugene Grosbein в Apr 18 12:12:06 по местному времени:

Dear Eugene,

15 Apr 18 03:46, you wrote to me:

VS>> Я пока не выяснил, что именно сделали с железом на удалённом
VS>> сервере, но картина такая: disk devices чем-то накрыло: # zpool
VS>> status
VS>> pool: zroot
VS>> state: ONLINE
VS>> scan: none requested
VS>> config:
VS>> NAME STATE READ WRITE CKSUM
VS>> zroot ONLINE 0 0 0
VS>> mirror-0 ONLINE 0 0 0
VS>> diskid/DISK-56K51TNLSp3 ONLINE 0 0 0
VS>> diskid/DISK-56K56YGASp3 ONLINE 0 0 0
VS>> errors: No known data errors
VS>> #
VS>> # ls /dev/ada*
VS>> /dev/ada0 /dev/ada1
VS>> #
VS>> # gpart show ada0
VS>> gpart: No such geom: ada0.

EG> gpart show без аргументов подсказал бы тебе правду.

Я и без него понял, что zpool пересел с физических устройств на diskid, весь вопрос почему это случилось? Система-то давно стоит.

# gpart show
=> 34 976773101 diskid/DISK-56K56YGAS GPT (466G)
34 6 - free - (3.0K)
40 1024 1 freebsd-boot (512K)
1064 984 - free - (492K)
2048 33554432 2 freebsd-swap (16G)
33556480 943216640 3 freebsd-zfs (450G)
976773120 15 - free - (7.5K)

=> 34 976773101 diskid/DISK-56K51TNLS GPT (466G)
34 6 - free - (3.0K)
40 1024 1 freebsd-boot (512K)
1064 984 - free - (492K)
2048 33554432 2 freebsd-swap (16G)
33556480 943216640 3 freebsd-zfs (450G)
976773120 15 - free - (7.5K)



VS>> У меня своп был настроен на /dev/ada0p2 и /dev/ada1p2,
VS>> соответственно после перезагрузки свопа не стало. Как вернуть
VS>> девайсы, точнее GPT разделы?

EG> Как уже написал Слава, сказать GEOM_LABEL'у не делать так.

Вопрос даже не в том, как сказать, а почему вдруг изменилось то, что до этого работало? Последнее обновление до 10.4-RELEASE-p8 могло дать такой эффект?

EG> А я бы ещё посоветовал не делать своп на ada[01], а делать на метках:

EG> glabel label swap0 /dev/ada0p2
EG> glabel label swap1 /dev/ada1p2

Система ставилась bsdinstall-ом практически по умолчанию, так что посоветовать можно только bsdinstall-лу или авторам его. Вот о kern.geom.label.gptid.enable они же позаботились в /usr/libexec/bsdinstall/zfsboot, а о kern.geom.label.disk_ident.enable почему-то нет.

EG> И своп делать на /dev/label/swap0 и /dev/label/swap1 -
EG> эти имена всегда будут доступны, неважно видится ли GPT
EG> у тебя на ada или на diskid.

VS>> "swapon /dev/diskid/DISK-56K51TNLSp2" помог как временная мера,
VS>> но хотелось бы знать, какой geom накрыл /dev/ada*

EG> GEOM_LABEL

Зачем он это сделал через 2 года эксплуатации системы, как думаешь?

VS>> и почему.

EG> Сложно сказать, не зная, что там у тебя настроено.

В том-то и дело, что ничего странного не настроено. Я вообще обычно ставлю эхотаг просто и бесхитростно, как инсталлятор предлагает.

Стояла система, поставленная bsdinstall-ом без всяких премудростей на зеркало. Всю жизнь zfs считал, что пулы живут на ada{0,1}p3, а после очередной перезагрузки вдруг передумал.

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Victor Sudakov написал(а) к Eugene Grosbein в Apr 18 12:44:50 по местному времени:

Dear Eugene,

15 Apr 18 12:12, I wrote to you:

[dd]

VS> Я и без него понял, что zpool пересел с физических устройств на
VS> diskid, весь вопрос почему это случилось? Система-то давно стоит.

Мне с той стороны написали, что "Был заменён только корпус, БП остался прежним.
Единственное что могло поменяться, это порядковый номер SATA разъема."

Это могло дать такой эффект? В эхотаге, что ли, где-то зашиты физические адреса устройств в zpool, типа как в Солярисе "/pci@111/pci@333/scsi@222/sd@0,0" в pathtoinst?

В "strings /boot/zfs/zpool.cache" какой-то phys_path, это там засада, да?

Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322

Eugene Grosbein написал(а) к Victor Sudakov в Apr 18 15:53:01 по местному времени:

15 апр. 2018, воскресенье, в 10:06 NOVT, Victor Sudakov написал(а):

SO>> kern.geom.label.disk_ident.enable=0
VS> 1. Оно по умолчанию "1" с момента установки системы. Что могло измениться после
VS> очередной перезагрузки (совпавшей со сменой железа), что пул пересел на
VS> /dev/diskid/* ?

geomlabel захватил провайдера geom_disk раньше, чем geompart.

VS> 2. Если я это таки напишу в loader.conf, и при следующей перезагрузке
VS> /dev/diskid/* не станет, не потеряю ли я данный пул совсем?

Нет, так как geompart никуда не денется, просто geomlabel перестанет
ему мешать.

VS> Отчего вообще зависит, на каких устройствах ZFS находит устройства с пулом?

От того, который из geom заберёт себе провайдера-disk,
а это, к сожалению, зависит от миллиона причин,
хотя и детерминировано.

Eugene
--- slrn/1.0.2 (FreeBSD)

Eugene Grosbein написал(а) к Victor Sudakov в Apr 18 15:57:16 по местному времени:

15 апр. 2018, воскресенье, в 10:12 NOVT, Victor Sudakov написал(а):

EG>> gpart show без аргументов подсказал бы тебе правду.
VS> Я и без него понял, что zpool пересел с физических устройств на diskid, весь
VS> вопрос почему это случилось?

От меня не видно.

VS>>> У меня своп был настроен на /dev/ada0p2 и /dev/ada1p2,
VS>>> соответственно после перезагрузки свопа не стало. Как вернуть
VS>>> девайсы, точнее GPT разделы?
EG>> Как уже написал Слава, сказать GEOM_LABEL'у не делать так.
VS> Вопрос даже не в том, как сказать, а почему вдруг изменилось то, что до этого
VS> работало? Последнее обновление до 10.4-RELEASE-p8 могло дать такой эффект?

Что угодно могло дать такой эффект.

EG>> А я бы ещё посоветовал не делать своп на ada[01], а делать на метках:
EG>> glabel label swap0 /dev/ada0p2
EG>> glabel label swap1 /dev/ada1p2
VS> Система ставилась bsdinstall-ом практически по умолчанию

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

VS> так что посоветовать можно только bsdinstall-лу или авторам его.

Нет, можно ещё посоветовать не доверять bsdinstall-лу
и подкладывать соломки самому, ну если тебе важна надёжность.

VS> Вот о kern.geom.label.gptid.enable
VS> они же позаботились в /usr/libexec/bsdinstall/zfsboot, а о
VS> kern.geom.label.disk_ident.enable почему-то нет.

И это только один из множества моментов.

EG>> И своп делать на /dev/label/swap0 и /dev/label/swap1 -
EG>> эти имена всегда будут доступны, неважно видится ли GPT
EG>> у тебя на ada или на diskid.
VS>>> "swapon /dev/diskid/DISK-56K51TNLSp2" помог как временная мера,
VS>>> но хотелось бы знать, какой geom накрыл /dev/ada*
EG>> GEOM_LABEL
VS> Зачем он это сделал через 2 года эксплуатации системы, как думаешь?

boot -v покажи.

EG>> Сложно сказать, не зная, что там у тебя настроено.
VS> В том-то и дело, что ничего странного не настроено. Я вообще обычно ставлю
VS> эхотаг просто и бесхитростно, как инсталлятор предлагает.

Это плохо.

VS> Стояла система, поставленная bsdinstall-ом без всяких премудростей на зеркало.
VS> Всю жизнь zfs считал, что пулы живут на ada{0,1}p3, а после очередной
VS> перезагрузки вдруг передумал.

Это не проблема zfs скорее всего, а геома.

Eugene
--
http://www.grosbein.net/papirosn.mp3
http://dadv.livejournal.com/2006/03/11/
--- slrn/1.0.2 (FreeBSD)

Eugene Grosbein написал(а) к Victor Sudakov в Apr 18 16:11:48 по местному времени:

15 апр. 2018, воскресенье, в 10:44 NOVT, Victor Sudakov написал(а):

VS>> Я и без него понял, что zpool пересел с физических устройств на
VS>> diskid, весь вопрос почему это случилось? Система-то давно стоит.
VS> Мне с той стороны написали, что "Был заменён только корпус, БП остался прежним.
VS> Единственное что могло поменяться, это порядковый номер SATA разъема."
VS> Это могло дать такой эффект?

Не исключено. Например, диски поменялись местами и на ada0
больше нет того компонента пула, который там лежал раньше
(теперь он на ada1) и наоборот.

VS> В эхотаге, что ли, где-то зашиты физические адреса
VS> устройств в zpool, типа как в Солярисе "/pci@111/pci@333/scsi@222/sd@0,0" в
VS> pathtoinst?

Не совсем так, но сами имена ada0/ada1 по сути есть функции
таких "физических" адресов:

# egrep 'ata.:.*on|ada. at' /var/run/dmesg.boot
ata0: <ATA channel> at channel 0 on atapci0
ata2: <ATA channel> at channel 0 on atapci1
ata3: <ATA channel> at channel 1 on atapci1
ada0 at ata2 bus 0 scbus1 target 0 lun 0
ada1 at ata3 bus 0 scbus2 target 0 lun 0

Поменяется физический порт (ada[23]) - поменяется имя ada[01],
а судя по всему, zpool.cache кеширует эти имена:

# zpool status | grep ONLINE
state: ONLINE
os ONLINE 0 0 0
raid/r0s2 ONLINE 0 0 0
state: ONLINE
z ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
raid/r1 ONLINE 0 0 0
raid/r2 ONLINE 0 0 0
# strings /boot/zfs/zpool.cache | fgrep raid
/dev/raid/r0s2
/dev/raid/r1
/dev/raid/r2


VS> В "strings /boot/zfs/zpool.cache" какой-то phys_path, это там засада, да?

Судя по сорцам, на фре phys_path не используется (#ifdef illumos).

Eugene
--- slrn/1.0.2 (FreeBSD)

Victor Sudakov написал(а) к Eugene Grosbein в Apr 18 15:50:40 по местному времени:

Dear Eugene,

15 Apr 18 15:57, you wrote to me:

EG>>> gpart show без аргументов подсказал бы тебе правду.
VS>> Я и без него понял, что zpool пересел с физических устройств на
VS>> diskid, весь вопрос почему это случилось?

EG> От меня не видно.

Как уже выяснилось, SATA диски физически поменяли местами.

[dd]

VS>> Система ставилась bsdinstall-ом практически по умолчанию

EG> Это плохо. bsdinstall тащем-то отвратный инсталлятор в этой части,
EG> он писан людьми с минимальным опытом администрирования,
EG> хотя как программисты они, может быть, и ничего.

VS>> так что посоветовать можно только bsdinstall-лу или авторам его.

EG> Нет, можно ещё посоветовать не доверять bsdinstall-лу
EG> и подкладывать соломки самому, ну если тебе важна надёжность.

Ну, я просто скромно считаю, что моя квалификация ещё ниже, чем у авторов bsdinstall.

[dd]
VS>> Зачем он это сделал через 2 года эксплуатации системы, как
VS>> думаешь?

EG> boot -v покажи.

Теперь уже не покажу, там может до EoL 10-ки ни одного ребута не будет.

EG>>> Сложно сказать, не зная, что там у тебя настроено.
VS>> В том-то и дело, что ничего странного не настроено. Я вообще
VS>> обычно ставлю эхотаг просто и бесхитростно, как инсталлятор
VS>> предлагает.

EG> Это плохо.

Может быть и плохо, но это оценка не меня, а инсталлятора. Уж инсталлятор должен создать пригодную к экспуатации систему, а иначе это негодная система.

VS>> Стояла система, поставленная bsdinstall-ом без всяких
VS>> премудростей на зеркало. Всю жизнь zfs считал, что пулы живут на
VS>> ada{0,1}p3, а после очередной перезагрузки вдруг передумал.

EG> Это не проблема zfs скорее всего, а геома.

Как же всё-таки zfs находит свои vdev-ы? Где-то запоминает имена устройств или каждый раз обшаривает все девайсы в поисках пулов и того, из чего пулы состоят? Зачем тогда /boot/zfs/zpool.cache ?

Если бы у меня диски в zfs mirror переехали с ada{0,1} на da{3,5}, или вообще на /dev/label/{foo,bar}, zpool из них всё равно собрался бы?

Солярис в такой ситуации скорее всего позорно не смог бы загрузиться. У меня был случай, когда пришлось перегенерять /etc/pathtoinst просто из-за того, что диск в другой IDE-слот переткнули (правда там был не zfs, но "буковки съехали").


Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--- GoldED+/BSD 1.1.5-b20160322-b20160322