Dobrze zaplanowane partycje Linuksa oszczędzają problemów przy reinstalacji, odzyskiwaniu danych i rozbudowie dysku. Największe znaczenie mają trzy rzeczy: schemat tablicy partycji, sposób montowania katalogów i to, czy system ma działać możliwie prosto, czy ma dawać elastyczność na przyszłość. W tym tekście pokazuję, jak dobrać układ dysku bez zbędnej teorii i bez typowych pułapek.
Najpierw warto ustalić schemat dysku i cel podziału
- Partycja to wydzielony fragment dysku, a system plików określa, jak Linux zapisuje tam dane.
- Na nowych komputerach zwykle wygrywa GPT z UEFI, a MBR ma sens głównie przy starszym sprzęcie lub zgodności.
- Najbezpieczniejszy punkt startu to osobny
/, opcjonalny/home, swap dopasowany do stylu pracy i/boot/efina UEFI. - Do przeglądania i diagnozy używaj
lsblk,blkidifdisk -l, a zmiany rób dopiero po kopii danych. - W
/etc/fstablepiej opierać się na UUID lub PARTUUID niż na nazwach typu/dev/sda1.
Jak Linux widzi dysk, partycję i system plików
Ja zawsze zaczynam od rozdzielenia trzech warstw, które początkujący często wrzucają do jednego worka. Dysk to fizyczne urządzenie, tablica partycji mówi, gdzie kończy się jeden obszar, a zaczyna drugi, a system plików decyduje, jak będą przechowywane katalogi, pliki i metadane. Sama partycja nie jest jeszcze katalogiem, więc /home może być osobną partycją, ale równie dobrze może siedzieć na tej samej, co /.
W praktyce Linux widzi nośniki jako urządzenia blokowe, na przykład /dev/sda albo /dev/nvme0n1, a ich partycje jako kolejne wpisy, takie jak /dev/sda1 czy /dev/nvme0n1p1. Dopiero po zamontowaniu partycji w konkretnym punkcie montowania, na przykład /, /home albo /var, zaczyna ona brać udział w codziennej pracy systemu. Jeśli ten porządek jest jasny, łatwiej ocenić, czy problem leży w układzie partycji, w samym systemie plików, czy w konfiguracji montowania. To prowadzi wprost do pytania, jaki schemat tablicy partycji wybrać.
GPT czy MBR i kiedy ma to znaczenie
Jak podaje dokumentacja Red Hata, GPT powstał po to, żeby wyjść poza ograniczenia starszego MBR. W praktyce wybór nie jest już kosmetyczny: na współczesnych maszynach z UEFI GPT jest rozsądniejszym domyślnym wyborem, a MBR zostawiam raczej dla starszych komputerów albo bardzo konkretnych scenariuszy zgodności.
| Kryterium | GPT | MBR |
|---|---|---|
| Nowe komputery | Naturalny wybór przy UEFI | Najczęściej tylko dla zgodności ze starym trybem bootowania |
| Liczba partycji | Dużo większa swoboda, bez klasycznego podziału na primary i logical | Do 4 partycji podstawowych albo 3 podstawowe i 1 rozszerzona |
| Dyski powyżej 2 TB | Praktycznie bezproblemowe | Staje się ograniczeniem |
| UEFI | Pasuje idealnie | Zwykle nie jest pierwszym wyborem |
| Odporny, nowoczesny układ | Lepszy start do nowych instalacji | Rozwiązanie starszej generacji |
Jeśli instaluję system na komputerze z UEFI, tworzę też EFI System Partition, zwykle w FAT32 i najczęściej w zakresie około 200-512 MiB, montowaną jako /boot/efi. Ta mała partycja jest potrzebna do uruchamiania systemu, więc nie traktuję jej jako miejsca na dane użytkownika. Reszta dysku może być prostsza niż wygląda na diagramach: jeden duży obszar na system i ewentualnie kolejne woluminy tam, gdzie naprawdę pomagają w utrzymaniu porządku. Gdy schemat bootowania jest już jasny, można przejść do praktycznego rozmieszczenia katalogów.
Jak ułożyć partycje sensownie dla domowego komputera
Ja nie zaczynam od pytania „ile partycji da się zrobić”, tylko od pytania „co ma się stać, gdy system trzeba będzie odtworzyć albo gdy dysk zacznie się zapełniać”. Na zwykłym laptopie lub desktopie najczęściej wystarczy prosty układ, bo zbyt rozdrobniony dysk szybciej staje się problemem niż pomocą. Jeśli nie masz konkretnego powodu, nie rozdzielaj każdego katalogu na osobną partycję.
| Scenariusz | Praktyczny układ | Kiedy ma sens |
|---|---|---|
| Domowy laptop lub komputer biurowy |
/boot/efi 200-512 MiB, / 30-60 GiB, swap jako plik, reszta na /home
|
Gdy chcesz prostoty i łatwej rozbudowy bez ciągłego zarządzania miejscem |
| Komputer do testów i eksperymentów |
/boot/efi, / 40-80 GiB, osobny /home
|
Gdy często reinstalujesz system albo testujesz różne dystrybucje |
| Serwer |
/boot/efi, /, czasem osobny /var, swap zależnie od pamięci RAM |
Gdy logi, kontenery lub usługi mogą szybko zapychać jeden obszar dysku |
W praktyce osobny /home najbardziej opłaca się wtedy, gdy często reinstalujesz system i chcesz zostawić dane użytkownika bez ruszania. Z kolei osobny /var ma sens głównie na serwerach, bo tam rosną logi, cache, dane usług i kontenery. Jeśli chodzi o swap, to na wielu desktopach wygodniejszy jest dziś plikiem swap niż osobną partycją, bo łatwiej go zmienić, a nie wymaga sztywnego planowania od początku. Osobna partycja swap przydaje się przede wszystkim wtedy, gdy świadomie planujesz hibernację albo chcesz prosty, przewidywalny układ niskopoziomowy. Po takim planie zostaje już tylko sprawdzenie, co naprawdę siedzi na dysku i jak bezpiecznie to zmieniać.
Jak sprawdzić układ dysku i bezpiecznie go zmienić
Do oceny stanu dysku sięgam zwykle po kilka prostych narzędzi zamiast po jedno „magiczne” polecenie. Najszybciej układ pokazuje lsblk, a jego wersja z informacją o systemach plików, etykietach i UUID, czyli lsblk -f, jest w praktyce najwygodniejsza do codziennej diagnozy. Do tego dorzucam fdisk -l albo parted -l, jeśli chcę zobaczyć samą tablicę partycji, oraz blkid, gdy sprawdzam identyfikatory używane później w montowaniu.
lsblk -f
fdisk -l
parted -l
blkidJak podaje man7, w /etc/fstab lepiej używać UUID albo PARTUUID niż nazw typu /dev/sda1. To drobna zmiana, ale realnie zmniejsza ryzyko, że po podłączeniu innego dysku albo po zmianie kolejności urządzeń system zacznie montować nie to, co trzeba. Przed zmianą partycji robię więc trzy rzeczy w tej kolejności: pełny backup, identyfikację właściwego dysku po rozmiarze i modelu, a dopiero potem edycję układu z poziomu live systemu albo przy odmontowanych woluminach. Taki porządek jest nudny, ale skuteczny, i dokładnie o to tu chodzi. Skoro wiesz już, jak sprawdzać dysk, warto znać pułapki, które najczęściej psują cały plan.
Najczęstsze błędy przy partycjonowaniu, które kosztują czas
- Mieszanie trybu bootowania z tablicą partycji - UEFI zwykle łączy się z GPT, a legacy BIOS z MBR; rozjazd między nimi często kończy się problemem z uruchomieniem systemu.
- Zbyt wiele małych partycji - na papierze wygląda to porządnie, ale w praktyce jedna z nich zaczyna puchnąć, a druga marnuje miejsce.
-
Montowanie po nazwie urządzenia -
/dev/sda1może się zmienić, więc bezpieczniej trzymać się UUID lub PARTUUID. - Zapomniana partycja EFI - na UEFI bez niej system zwyczajnie nie wystartuje.
- Praca na złym dysku - jeśli masz kilka nośników, zawsze sprawdzaj pojemność i model, a nie tylko literę urządzenia.
- Brak kopii zapasowej przed zmianą rozmiaru - przesuwanie granic partycji nie jest operacją, którą robię „na żywo” bez planu awaryjnego.
Najbardziej kosztowny błąd to nie sam zły podział, tylko przekonanie, że da się go bezpiecznie poprawić bez przygotowania. Dlatego traktuję partycjonowanie jak decyzję administracyjną, a nie estetyczną: ma działać, dać się utrzymać i nie utrudniać odzysku po awarii. Kiedy te zasady są pod kontrolą, wybór układu staje się dużo prostszy.
Prosty układ, który zwykle wygrywa w codziennym użyciu
Gdybym miał wskazać jeden domyślny układ dla większości osób, postawiłbym na GPT, UEFI, jedną małą partycję EFI, jeden sensownie duży / i swap w formie pliku. Taki zestaw daje mało punktów awarii, łatwo go rozbudować i nie wymaga ciągłego pilnowania, czy któraś sekcja dysku nie jest już za mała. Jeśli ktoś często reinstaluje system, wtedy dokładałbym osobny /home; jeśli to serwer, rozważyłbym jeszcze /var albo LVM, ale tylko wtedy, gdy faktycznie przynosi to korzyść.
Najważniejsza rzecz, którą zostawiam na koniec, jest prosta: układ partycji ma ułatwiać życie, a nie udowadniać techniczną ambicję. W większości przypadków wygrywa rozwiązanie trochę mniej efektowne, ale bardziej przewidywalne. Jeśli oprzesz montowanie na UUID, zostawisz margines na wzrost danych i nie zrobisz z dysku labiryntu, to Linux odwdzięczy się spokojną pracą zamiast ciągłych interwencji.
