Rozwiązanie społecznościowe

Scalowanie pamięci CasaOS za pomocą zewnętrznego dysku SSD: dlaczego większa ilość miejsca /DATA nie powiększa głównej partycji Linuksa

A June-September 2025 CasaOS thread where a ZimaBoard owner asked whether merging an external SSD into the system storage was reliable. One user reported no issues initially. The OP later tried the beta merge and gained hundreds of GB in the combined CasaOS storage view, but soon hit no-space errors on the internal chip/root again. The thread illustrates that CasaOS MergerFS-style /DATA aggregation does not enlarge the underlying Linux root filesystem.

The source user expected CasaOS “Merge” to turn the small internal eMMC plus an external SSD into one large physical system partition. That is not what the feature does. The merge can present multiple storage locations together under CasaOS's /DATA view, but the Linux root filesystem, package manager, Docker root directory, and individual physical disks still exist underneath.

Użytkownik źródłowy oczekiwał, że funkcja CasaOS „Merge” zamieni mały wewnętrzny moduł eMMC i zewnętrzny dysk SSD w jedną dużą fizyczną partycję systemową. Ta funkcja nie działa w ten sposób. Połączenie może prezentować wiele lokalizacji pamięci masowej razem pod apt-get upgrade widok, ale główny system plików Linuksa, menedżer pakietów, główny katalog Dockera oraz poszczególne dyski fizyczne nadal istnieją pod spodem. kończące się błędem To wyjaśnia wynik opisany w źródle: interfejs pokazywał setki gigabajtów wolnego miejsca w połączonej pamięci systemowej, jednak /DATA a wewnętrzny układ ponownie wyglądał na pełny. Większa logiczna pojemność później powróciła

nie przeniosło automatycznie każdego zapisu na poziomie katalogu głównego na dysk SSD.

Użytkownik zapytał konkretnie o funkcję beta Merge w CasaOS

Zima-Giorgio początkowo zasugerował przeniesienie obrazów i woluminów Dockera na inne urządzenie pamięci masowej. OP wyjaśnił, że woluminy Dockera nie były głównym problemem — pytanie dotyczyło tego, czy sama funkcja Merge w interfejsie pamięci masowej CasaOS jest niezawodna.

Inny użytkownik zgłosił udane połączenie

radioamerica7 odpowiedział, że połączyli pamięć masową i wszystko „działało zgodnie z oczekiwaniami”, bez żadnych problemów.

Zachęciło to OP do podjęcia próby, ale krótkotrwały sukces nie dał odpowiedzi na ważniejsze pytanie dotyczące głównego systemu plików.

OP dodał dysk SSD, a proces łączenia zakończył się bez problemów

Później Xan dodał dysk SSD za pomocą kabla Y i połączył go z pamięcią masową CasaOS. Interfejs nadal pokazywał wewnętrzny układ jako mały, ale łączna przestrzeń dyskowa miała do dyspozycji setki gigabajtów.

Przez kilka dni konfiguracja wydawała się działać.

Następnie powróciły objawy braku miejsca na poziomie katalogu głównego

  • OP zaczął obserwować znajome objawy:
  • kontenery Docker nie uruchamiały się prawidłowo;
  • apt-get upgrade błędami PHP; kończące się błędem;
  • brak wolnego miejsca na urządzeniu

wewnętrzny układ zgłaszał nieprawidłowe lub nieokreślone informacje o wolnym miejscu.

To najważniejszy dowód w tym wątku.

CasaOS historycznie używał MergerFS do agregowania /DATA /DATA. Historyczny przykład pokazuje, że główny system plików Linuksa nadal był zamontowany oddzielnie, podczas gdy implementacja CasaOS LocalStorage firmy IceWhale oraz historia publicznych zgłoszeń opisują połączony widok jako kombinację w stylu MergerFS obszaru plików CasaOS i dodatkowej pamięci masowej pod /DATA obejmuje wiele podstawowych ścieżek.

Zobacz architekturę połączonego magazynu CasaOS.

MergerFS nie zwiększa rozmiaru głównego systemu plików ext4

Pliki zapisywane w ścieżkach poza połączonym drzewem — na przykład dane menedżera pakietów, dzienniki, części domyślnego katalogu głównego Dockera oraz zwykłe pliki systemu Linux — nadal zajmują miejsce na fizycznym systemie plików partycji głównej.

Dlatego apt może zabraknąć miejsca, nawet gdy połączony /DATA widok zgłasza dużą ilość wolnego miejsca.

Obrazy/woluminy Dockera wymagają osobnego planu migracji

Dlatego Giorgio najpierw zasugerował użytkownikowi przeniesienie obrazów i woluminów Dockera. Dane aplikacji mogą być duże, a zmiana widocznej puli pamięci CasaOS nie musi przenosić katalogu głównego Dockera ani każdego istniejącego woluminu.

Przed zmianą ścieżek przechowywania Dockera wykonaj kopię zapasową konfiguracji kontenerów i AppData oraz zastosuj aktualną metodę migracji CasaOS/Dockera odpowiednią dla zainstalowanego systemu operacyjnego hosta.

Funkcja źródłowa była wyraźnie oznaczona jako wersja beta

Autor pytania wielokrotnie zauważał, że funkcja łączenia była w wersji beta. Publiczna historia zgłoszeń CasaOS również zawiera wcześniejsze błędy związane z połączonym magazynem oraz prośby o zmiany w projekcie. Należy traktować ją jako wygodną warstwę tworzenia puli, a nie zamiennik zrozumienia układu fizycznych dysków i partycji głównej.

Bardziej przewidywalny układ pamięci oddziela poszczególne role

W przypadku małego domowego serwera eMMC/SBC bardziej przejrzysty układ wygląda następująco:

  • system operacyjny/partycja główna na urządzeniu systemowym z wystarczającym zapasem wolnego miejsca;
  • Docker/AppData na dysku SSD lub w innej celowo wybranej ścieżce przechowywania;
  • duże pliki multimedialne/pobrane na osobnym magazynie o dużej pojemności;
  • kopia zapasowa na innym urządzeniu.

Dzięki temu łatwiej ustalić, „który fizyczny dysk jest pełny”, niż polegać na jednej liczbie w interfejsie puli.

FAQ dotyczące funkcji CasaOS Merge Storage

Czy funkcja CasaOS Merge zapewniła użytkownikowi większą widoczną pojemność /DATA?

Tak. Po dodaniu dysku SSD połączony widok pokazywał setki gigabajtów wolnego miejsca.

Czy zapobiegło to ponownemu zapełnieniu pamięci wewnętrznej/głównej?

Nie. Później u autora pytania pojawiły się objawy braku miejsca na poziomie partycji głównej, w tym nieudane apt-get upgrade.

Czy połączone /DATA oznacza, że partycja główna systemu Linux fizycznie się powiększa?

Nie. Pula w stylu MergerFS łączy ścieżki na poziomie systemu plików; nie zwiększa rozmiaru bazowej partycji głównej.