Co powoduje, że zbiór danych ZFS jest pusty mimo pomyślnego zamontowania?
Zbiór danych ZFS może być zgłaszany jako zamontowany, a mimo to wyglądać na pusty, gdy oczekiwane dane znajdują się w zbiorze podrzędnym, są ukryte przez punkt montowania lub są dostępne pod innym głównym punktem importu.
Flaga zamontowania potwierdza, że jeden zbiór danych jest dołączony do jednej ścieżki; nie oznacza jednak, że jest to ścieżka oczekiwana przez aplikację lub użytkownika, że zamontowano pod nią zbiory podrzędne ani że odblokowano zaszyfrowanego potomka. Pusty nadrzędny zbiór danych może być całkowicie sprawny, gdy wszystkie rzeczywiste pliki znajdują się w zbiorach podrzędnych. Zanim skopiujesz dane lub zmienisz strukturę puli, porównaj właściwości zbioru danych, zajęte miejsce, tabele montowania i widok katalogu.
Porównaj zajętość zbioru danych z otwartym katalogiem
Zapisz nazwę zbioru danych oraz wartości USED, REFER, AVAIL, MOUNTPOINT i MOUNTED. Następnie wyświetl dokładny katalog pokazany użytkownikowi lub aplikacji.
Jeśli zbiór danych zgłasza prawie brak danych referencyjnych, pliki mogą należeć do zbioru podrzędnego, migawki, klonu lub innego zbioru danych o podobnej nazwie. Podręcznik ZFS dla FreeBSD opisuje zbiory danych jako osobno zarządzane systemy plików, dlatego użycie całej puli i zawartość jednego otwartego katalogu nie muszą dotyczyć tego samego zbioru danych.
Nie wnioskuj o utracie danych wyłącznie na podstawie graficznej przeglądarki plików. Porównaj widok właściwości ZFS, tabelę montowania systemu operacyjnego oraz lokalną powłokę roota uruchomioną poza kontenerem lub ograniczoną przestrzenią nazw aplikacji.
Sprawdź jednocześnie właściwości mountpoint, mounted i canmount
Sprawdź, czy punkt montowania zbioru danych jest określony jawnie czy dziedziczony, czy zbiór jest rzeczywiście zamontowany w tej ścieżce oraz czy canmount ma wartość on, off lub noauto.
Dokumentacja właściwości ZFS firmy Oracle wyjaśnia, że wartości mountpoint i canmount określają, czy zbiór danych jest montowany automatycznie, tylko na żądanie, czy służy wyłącznie do przekazywania właściwości potomkom.
Zbiór danych może przekazywać właściwości dziedziczone swoim dzieciom, pozostając celowo niezamontowany. Z kolei zbiór danych korzystający ze starszego punktu montowania może wyglądać poprawnie we właściwościach ZFS, ale zależeć od osobnego wpisu montowania systemu, który nie został wykonany.
Sprawdź montowanie nadrzędnych i podrzędnych zbiorów danych
Wyświetl pełne drzewo zbiorów danych w puli i posortuj je według punktu montowania. Porównaj nadrzędny zbiór danych z każdym dzieckiem, które powinno zawierać pliki użytkowników, dane aplikacji, kopie zapasowe lub multimedia.
Pusty nadrzędny zbiór danych jest częsty, gdy służy wyłącznie do organizowania właściwości i punktów montowania. Przestrzeń nazw zbiorów danych ZFS systemu FreeBSD traktuje każde dziecko jako osobno zarządzany zbiór danych, dlatego pool/data może być pusty, podczas gdy pool/data/photos zawiera rzeczywiste pliki.
Jeśli nadrzędny zbiór danych jest zamontowany, ale dziecko nie, zdiagnozuj dziecko niezależnie. Sprawdź canmount, klucze szyfrowania, kolidujące punkty montowania, nieudane importy oraz to, czy usługa nie uruchomiła się przed zakończeniem montowania dziecka.
Sprawdź, czy montowanie nie ukryło plików znajdujących się już w katalogu
Pliki mogą znajdować się w zwykłym katalogu przed zamontowaniem na nim zbioru danych. Po zamontowaniu zbioru danych ZFS znajdujące się pod spodem pliki są ukryte w tej ścieżce, choć nadal pozostają w głównym systemie plików.
Odłącz zbiór danych wyłącznie podczas kontrolowanego okna serwisowego i sprawdź katalog znajdujący się pod spodem z poziomu hosta. Podręcznik montowania systemu Linux stwierdza, że istniejąca wcześniej zawartość punktu montowania staje się niewidoczna, gdy zamontowany system plików zajmuje tę ścieżkę.
Może wystąpić również odwrotna awaria: oczekiwane montowanie ZFS nie powiedzie się, pozostawiając użytkownikom i kontenerom widoczny pusty katalog znajdujący się pod spodem. Zdrowy zbiór danych może wtedy wyglądać na pusty, choć po prostu nie jest dołączony do ścieżki udostępnianej użytkownikom.
Wyklucz alternatywny katalog główny i starszy sposób montowania
Sprawdź, czy pula została zaimportowana z alternatywnym katalogiem głównym, opcją odzyskiwania, tymczasową ścieżką montowania lub inną nazwą puli. Zbiór danych może być poprawnie zamontowany pod poprzedzoną prefiksem ścieżką odzyskiwania zamiast w zwykłej lokalizacji produkcyjnej.
Import puli z alternatywnym katalogiem głównym zmienia położenie punktów montowania zbiorów danych względem tego tymczasowego katalogu. dokumentacja zpool import systemu Ubuntu wyjaśnia, że -R ustawia właściwość altroot, a -N może zaimportować pulę bez montowania systemów plików.
Sprawdź także zbiory danych, których punkt montowania ma wartość legacy. W tym trybie ZFS nie zarządza montowaniem automatycznie, więc źródłem prawdy staje się konfiguracja montowania systemu operacyjnego.
Sprawdź zaszyfrowane zbiory podrzędne i przestrzenie nazw montowania kontenerów
Zaszyfrowany zbiór podrzędny może pozostać niedostępny po zamontowaniu rodzica, jeśli klucz nie został załadowany lub montowanie dziecka nie powiodło się. Katalog nadrzędny wygląda wtedy na pusty lub niepełny, mimo że pula działa.
Zweryfikuj stan kluczy i montowania każdego zaszyfrowanego potomka, a następnie porównaj ścieżkę hosta ze ścieżką udostępnioną kontenerowi. Dokumentacja LXD firmy Canonical wyjaśnia, że urządzenia dyskowe kontenera mapują źródła hosta na osobne ścieżki instancji, dlatego zbiór podrzędny widoczny na hoście może nadal być niedostępny w starszym montowaniu kontenera.
Jeśli host widzi dane, ale kontener nie, sprawdź źródło dowiązania bind i propagację montowania. Kontener utworzony przed zamontowaniem dziecka ZFS może nadal widzieć znajdujący się pod spodem pusty katalog, dopóki usługa nie zostanie utworzona ponownie lub montowanie nie będzie prawidłowo propagowane.
Przywróć właściwy widok bez kopiowania zbioru danych
Napraw najmniejszą potwierdzoną nieprawidłowość właściwości lub ścieżki: zamontuj brakujące dziecko, popraw dziedziczony punkt montowania, usuń niezamierzony alternatywny katalog główny, napraw starszy wpis montowania, załaduj klucz szyfrowania lub utwórz kontener ponownie z właściwym źródłem dowiązania bind.
lista kontrolna odzyskiwania serwera domowego ZimaSpace zawiera powiązaną zasadę: przed uruchomieniem narzędzi naprawczych lub przywróceniem danych sprawdź warstwę pamięci masowej i stan montowania.
Diagnoza jest zakończona, gdy oczekiwany zbiór danych i zbiory podrzędne są zamontowane w odpowiednich ścieżkach, zajętość referencyjna odpowiada widocznym plikom, aplikacje widzą to samo drzewo co host, a układ przetrwa eksport, import, ponowne uruchomienie usługi i restart systemu.
Polecane produkty
Wsparcie i wskazówki
Więcej do przeczytania
Przewodnik po pamięci masowej nagrywania telewizji na żywo: pojemność, przechowywanie i czyszczenie
Zmierz rzeczywiste nagrania, zarezerwuj zapas, połącz limity wieku i pojemności oraz potwierdź, że najstarszy kwalifikujący się program zostanie usunięty, zanim pamięć się zapełni.
Proces odzyskiwania metadanych multimediów domowych po przywróceniu bazy danych
Zabezpiecz przywrócony stan, zweryfikuj tożsamość multimediów i ścieżki, a następnie napraw brakujące grafiki lub dopasowania w pilotażowej bibliotece przed wprowadzeniem szeroko zakrojonych zmian metadanych.
Lista zgodności klientów Jellyfin z dźwiękiem, obrazem i napisami
Testuj reprezentatywne pliki, zmieniając jedną zmienną naraz, i rejestruj dla każdego klienta: bezpośrednie odtwarzanie, remultipleksowanie, konwersję dźwięku, transkodowanie wideo lub niepowodzenie.
