Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
zfs i niewidoczne zasoby
23 views
Skip to first unread message
Jacek 'Szumak' Kotlarski
Feb 7, 2012, 5:09:54 PM2/7/12
to
Witam, mam dziwny problem i nie mogę znaleźć rozwiązania.
System FBSD 9.0R
Instalacja przebiegła wg:
http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/9.0-RELEASE
Geneza problemu:
System zainstalowany w puli "zroot" (mirror), w systemie dostępne były
dwie inne pule na 4 dyskach w 2 mirrorach: zdata - (/export2) i zdb -
(/var/databases).
W dniu dzisiejszym właściciel serwera wyjął 2 dyski z puli "zdb" nie
eksportując jej z systemu. Oczywiście po tym zabiegu system nie wstał
poprawnie i tu zaczyna się mój problem:
- pierwsze co zrobiłem to usunąłem niedostępną pulę zdb z systemu,
zostały więc dwie, teoretycznie sprawne pule; jednakże zasoby nie są
prawidłowo montowane w systemie - przykładowo wygląda to tak:
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zroot 54.0G 844G 357M legacy
zroot/home 9.61G 844G 9.61G /home
zroot/tmp 1.5M 844G 1.5M /tmp
zroot/usr 2.57G 844G 2.57G /usr
zroot/var 41.4G 844G 41.4G /var
niby wygląda wszystko dobrze (pula zdata nie jest tu zaimportowana), ale:
# ls /home
# ls /var
# ls /tmp
# ls /usr
# ls /
.cshrc dev lib rescue .... <- tutaj są wszystkie pliki widoczne, we
wcześniejszych katalogach nie.
Jeżeli teraz wykonam ręcznie:
zfs set mountpoint=none zroot/usr
zfs set mountpoint=/usr zroot/usr
to zawartość /usr pojawia się w postaci kompletnej i nienaruszonej.
Niestety, po ponownym restarcie problem powraca.
Co więcej: usunąłem i wygenerowałem powtórnie zpool.cache postępując wg
procedury użytej w trakcie instalacji, niestety bez pozytywnego efektu.
zpool status nie pokazuje jakichkolwiek błędów.
Mam zagwozdkę, nie wiem co może być przyczyną.
System FBSD 9.0R
Instalacja przebiegła wg:
http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/9.0-RELEASE
Geneza problemu:
System zainstalowany w puli "zroot" (mirror), w systemie dostępne były
dwie inne pule na 4 dyskach w 2 mirrorach: zdata - (/export2) i zdb -
(/var/databases).
W dniu dzisiejszym właściciel serwera wyjął 2 dyski z puli "zdb" nie
eksportując jej z systemu. Oczywiście po tym zabiegu system nie wstał
poprawnie i tu zaczyna się mój problem:
- pierwsze co zrobiłem to usunąłem niedostępną pulę zdb z systemu,
zostały więc dwie, teoretycznie sprawne pule; jednakże zasoby nie są
prawidłowo montowane w systemie - przykładowo wygląda to tak:
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
zroot 54.0G 844G 357M legacy
zroot/home 9.61G 844G 9.61G /home
zroot/tmp 1.5M 844G 1.5M /tmp
zroot/usr 2.57G 844G 2.57G /usr
zroot/var 41.4G 844G 41.4G /var
niby wygląda wszystko dobrze (pula zdata nie jest tu zaimportowana), ale:
# ls /home
# ls /var
# ls /tmp
# ls /usr
# ls /
.cshrc dev lib rescue .... <- tutaj są wszystkie pliki widoczne, we
wcześniejszych katalogach nie.
Jeżeli teraz wykonam ręcznie:
zfs set mountpoint=none zroot/usr
zfs set mountpoint=/usr zroot/usr
to zawartość /usr pojawia się w postaci kompletnej i nienaruszonej.
Niestety, po ponownym restarcie problem powraca.
Co więcej: usunąłem i wygenerowałem powtórnie zpool.cache postępując wg
procedury użytej w trakcie instalacji, niestety bez pozytywnego efektu.
zpool status nie pokazuje jakichkolwiek błędów.
Mam zagwozdkę, nie wiem co może być przyczyną.
Edward Tomasz Napierala
Feb 9, 2012, 7:40:40 AM2/9/12
to
Masz zfs_enable="YES" w /etc/rc.conf?
--
If you cut off my head, what would I say? Me and my head, or me and my body?
Jacek 'Szumak' Kotlarski
Feb 9, 2012, 11:22:30 AM2/9/12
to
W dniu 09.02.2012 13:40, Edward Tomasz Napierala pisze:
przykładowym scenariuszem instalacji.
Co więcej: w dokumentacji do zfs znalazłem zapis, że taka sytuacja może
mieć miejsce, jednak ponowne wygenerowanie zpool.cache miało ją jakoby
naprawiać - w najświeższej mojej instalacji niestety nie naprawia.
Podstawy ZFS poznawałem jeszcze na solarisie, tam nie spotkałem się
dotychczas z podobnym problemem - może to jakiś bug w implementacji?
Co jeszcze udało mi się ustalić? Mianowicie przywrócenie dostępu do
zasobów następowało jedynie w wyniku zmiany punktu montowania danego
zasobu, a więc tak jak w przytoczonym wcześniej przypadku (dla /usr),
ustawienie tego samego punktu montowania (bez jego zmiany) nie
przynosiło skutku pozytywnego.
Wobec tego z sytuacją poradziłem sobie ustawiając wszędzie
mountpoint=none i montując zasoby poprzez wpisy w /etc/fstab oraz
usuwając wpis vfs.root.mountfrom="zfs:zroot" z /boot/loader.conf
niemniej jednak jest to obejście problemu a nie jego rozwiązanie :-S
> Jeśli zamiast tego zrobisz "zfs mount -a", to też jest dobrze?
> Masz zfs_enable="YES" w /etc/rc.conf?
Pierwszego nie sprawdziłem, drugie oczywiście - zgodnie z przytoczonym
> Masz zfs_enable="YES" w /etc/rc.conf?
przykładowym scenariuszem instalacji.
Co więcej: w dokumentacji do zfs znalazłem zapis, że taka sytuacja może
mieć miejsce, jednak ponowne wygenerowanie zpool.cache miało ją jakoby
naprawiać - w najświeższej mojej instalacji niestety nie naprawia.
Podstawy ZFS poznawałem jeszcze na solarisie, tam nie spotkałem się
dotychczas z podobnym problemem - może to jakiś bug w implementacji?
Co jeszcze udało mi się ustalić? Mianowicie przywrócenie dostępu do
zasobów następowało jedynie w wyniku zmiany punktu montowania danego
zasobu, a więc tak jak w przytoczonym wcześniej przypadku (dla /usr),
ustawienie tego samego punktu montowania (bez jego zmiany) nie
przynosiło skutku pozytywnego.
Wobec tego z sytuacją poradziłem sobie ustawiając wszędzie
mountpoint=none i montując zasoby poprzez wpisy w /etc/fstab oraz
usuwając wpis vfs.root.mountfrom="zfs:zroot" z /boot/loader.conf
niemniej jednak jest to obejście problemu a nie jego rozwiązanie :-S
Rafał Wilk
Feb 9, 2012, 11:43:44 AM2/9/12
to
W dniu 2012-02-09 17:22, Jacek 'Szumak' Kotlarski pisze:
> Co jeszcze udało mi się ustalić? Mianowicie przywrócenie dostępu do
> zasobów następowało jedynie w wyniku zmiany punktu montowania danego
> zasobu, a więc tak jak w przytoczonym wcześniej przypadku (dla /usr),
> ustawienie tego samego punktu montowania (bez jego zmiany) nie
> przynosiło skutku pozytywnego.
> Wobec tego z sytuacją poradziłem sobie ustawiając wszędzie
> mountpoint=none i montując zasoby poprzez wpisy w /etc/fstab oraz
> usuwając wpis vfs.root.mountfrom="zfs:zroot" z /boot/loader.conf
> niemniej jednak jest to obejście problemu a nie jego rozwiązanie :-S
Sprawdź czy zpool.cache (po ponownym utworzeniu) masz w dobrym /boot.
Pozdrawiam
Rafał Wilk
> Co jeszcze udało mi się ustalić? Mianowicie przywrócenie dostępu do
> zasobów następowało jedynie w wyniku zmiany punktu montowania danego
> zasobu, a więc tak jak w przytoczonym wcześniej przypadku (dla /usr),
> ustawienie tego samego punktu montowania (bez jego zmiany) nie
> przynosiło skutku pozytywnego.
> Wobec tego z sytuacją poradziłem sobie ustawiając wszędzie
> mountpoint=none i montując zasoby poprzez wpisy w /etc/fstab oraz
> usuwając wpis vfs.root.mountfrom="zfs:zroot" z /boot/loader.conf
> niemniej jednak jest to obejście problemu a nie jego rozwiązanie :-S
Pozdrawiam
Rafał Wilk
Jacek 'Szumak' Kotlarski
Feb 9, 2012, 3:14:37 PM2/9/12
to
W dniu 09.02.2012 17:43, Rafał Wilk pisze:
tworzyłem /tmp/zpool.cache importując wszystko ręcznie, na koniec
przeniosłem go do /boot/zfs/ skąd wcześniej został usunięty.
> Sprawdź czy zpool.cache (po ponownym utworzeniu) masz w dobrym /boot.
Tego jestem pewien. Zrobiłem restart po skasowaniu i ponownie
tworzyłem /tmp/zpool.cache importując wszystko ręcznie, na koniec
przeniosłem go do /boot/zfs/ skąd wcześniej został usunięty.
0 new messages