Dan Lukes wrote:
> Zrejme mi unika duvod, proc trvas na importu. Ano, tim vznika potiz - bez
> predchoziho exportu import mozny neni.
Kdyz chces namontovat dataset (file system) z poolu, tak musi byt pool
importovany.
Kdyz se bootuje ze ZFS, tak se myslim ten pool importuje implicitne a myslim,
ze dokonce i kdyz byl pouzivan na jinem pocitaci a nebyl exportovany. Ale
nejsem si uplne jisty.
>> Ted ale kdyz se divam do /etc/rc.d/zfs, tak ten dela `zfs mount -va`, takze
>> by melo stacit udelat rc.skript, ktery se pusti pred tim zfs a ktery ten
>> base pool exportuje
>
> Kdyz to jde dolu. A kdyz to jde nahodu, tak zase naimportuje. Nebo ne ?
Ne. Kdyz to jde dolu tak to exportovat nemuzu, kdyz je jeste namontovany root.
A ten se odmontuje az po tech shutdown skriptech.
Kdyz to jde nahoru, tak jsou oba pooly v case spusteni /etc/rc.d/zfs
importovane. Tak jsem to myslel tak, ze pred /etc/rc.d/zfs ten base pool
exportuju (a `zfs mount -va` ty filesystemy/datasety nenamontuje).
>> Az se k tomu zase dostanu, tak to vyzkousim.
>
> Na to ti staci rc.d script s
>
> # REQUIRE: zfsbe
> # BEFORE: zfs
Diky za tip. Dal jsem to takto a funguje to bez problemu.
/etc/rc.d/majo-export-base
#!/bin/sh
#
# Based on /etc/rc.d/local
#
# PROVIDE: majo-export-base
# REQUIRE: zfsbe
# BEFORE: zfs
. /etc/rc.subr
name="local"
desc="Export base ZFS pool after reroot"
start_cmd="local_start"
stop_cmd="local_stop"
local_start()
{
echo 'Majo base:'
zpool export base
}
local_stop()
{
}
load_rc_config $name
run_rc_command "$1"
>> Nejvic by se mi hodilo, kdyby po rerootu si ten novy system z pohledu ZFS
>> myslel, ze je “jiny pocitac”.
>
> To by ti ale preci nepomohlo. Ten zpool by nebyl exportovany, nebyl by ani na
> tom novem pocitaci naimportovany, takze bys byl v situaci kterou nelze
> vyresit "normalne", nutne jsou recovery postupy. To mi moc jako "by se
> hodilo" stav nepripada.
No prave pred rerootem ho pouzival host s ID A a neexportoval ho… po rerootu je
to host s ID B… a protoze neni exportovany a posledne ho pouzival host s ID A,
tak si ho host s ID B nebude vsimat. Teda to jsem ocekaval.
Jenze host B po rerootu ma naimportovane oba pooly. “Svuj” private pool
implicitne, protoze z neho bootuje. A ten “cizi” base asi proto, ze to “zustane
v kernelu” u toho rerootu.
Vypada to tak, ze ZFS skutecne pouziva nakonfigurovane kern.hostid. Usuzuji to
z teto hlasky:
# zpool import -R /mnt private
cannot import 'private': pool may be in use from other system, it was last
accessed by shockwave (hostid: 0xcedff5b7) on Mon Jun 10 14:17:07 2019
Pritom hostid odpovida tomu ktere se vypisuje na konzoli pri bootu.
Zjistit to posledni hostid u ZFS poolu lze pomoci zdb -eC private
(http://wiki.lustre.org/Examining_ZFS_Pools_with_zdb).
Zaver asi je, ze u rerootu zustavaji zarizeni (prenasi se devfs), takze i zfs
zarizeni a tedy i ten zfs pool zustane po rerootu importovany, i kdyz by se
normalne neimportoval, protoze hostid je jine.
> Nemuzu si pomoct, ale v souvislosti se ZFS se mi neodbytne vybavuje Murphyho:
>
>> Počítač je zařízení sloužící k řešení problémů, které by bez něj vůbec
>> nevznikly.
njn.
Marian
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
