Dysk komputerowy to tylko część układanki, jeśli chcesz mieć system, który da się łatwo rozbudować, zaszyfrować i odzyskać po awarii. W praktyce liczy się to, jak podzielisz przestrzeń na partycje, jaki schemat tablicy wybierzesz i gdzie zamontujesz system oraz dane. Pokażę to bez zbędnej teorii: od różnicy między partycją a systemem plików, przez GPT i MBR, po sensowny układ pod Linuksa i szybkie sprawdzenie obecnej konfiguracji.
Najkrótsza droga do sensownego układu partycji
- GPT jest dziś domyślnym wyborem na większości współczesnych komputerów, a MBR zostaje głównie dla starej zgodności.
- Na UEFI zwykle potrzebujesz partycji
/boot/efi; bez niej system nie wystartuje poprawnie. -
/i/homewarto planować osobno, jeśli chcesz łatwiej reinstalować system bez ruszania danych. -
swapdobiera się do ilości RAM i do tego, czy chcesz hibernację, a nie według starej zasady „tyle samo co pamięć”. - Przed zmianą czegokolwiek sprawdź układ komendami
lsblk,fdisk -liblkid.
Czym jest partycja i dlaczego to coś więcej niż katalog
Partycja to wydzielony fragment nośnika, a nie gotowy folder z plikami. Dopiero gdy na tej przestrzeni założysz system plików, taki jak ext4, Btrfs czy XFS, i zamontujesz go w konkretnym miejscu, staje się on użyteczny dla systemu. Ja zwykle rozbijam ten temat na trzy pojęcia: tablica partycji opisuje układ dysku, system plików organizuje dane, a punkt montowania mówi, gdzie ten obszar ma się pojawić w drzewie katalogów, na przykład jako / albo /home.
To rozróżnienie ma znaczenie praktyczne. Gdy system nie startuje, często problem nie leży w samym dysku, tylko w tym, że bootloader nie widzi właściwej partycji albo że punkt montowania został źle wpisany do /etc/fstab. Dlatego przy planowaniu zawsze patrzę szerzej niż na sam rozmiar nośnika: myślę o tym, co ma się z niego uruchamiać, co ma być łatwe do backupu i co można później rozszerzyć bez bólu. Skoro te pojęcia są już rozdzielone, przechodzę do wyboru, który najczęściej decyduje o całej reszcie: GPT albo MBR.

GPT czy MBR w praktyce
| Cecha | GPT | MBR | Co to znaczy w praktyce |
|---|---|---|---|
| Obsługa współczesnych komputerów | Tak, to standard na nowych maszynach | Głównie zgodność wsteczna | Na nowym sprzęcie GPT jest rozsądniejszym wyborem |
| Limit pojemności | Bardzo wysoki, bez problemu dla dużych dysków | Około 2 TiB przy sektorach 512 B | Jeśli nośnik ma ponad 2 TiB, MBR staje się hamulcem |
| Liczba partycji | Domyślnie 128 wpisów | 4 partycje podstawowe, dalej kombinacje z rozszerzoną | GPT upraszcza układ i usuwa sztuczne ograniczenia |
| Odzyskiwanie po uszkodzeniu | Ma kopię zapasową tablicy na końcu dysku | Brak takiego mechanizmu | GPT jest po prostu odporniejszy na awarie metadanych |
| Bootowanie | Naturalny wybór dla UEFI; przy BIOS i GPT czasem potrzeba małej partycji BIOS Boot | Pasuje do starych komputerów BIOS | Tryb startu systemu ma znaczenie, nie tylko sam schemat partycji |
Jeśli nie mam mocnego powodu, żeby zostać przy starszej zgodności, wybieram GPT. Daje większą elastyczność, lepiej pasuje do UEFI i lepiej skaluje się przy większych dyskach. MBR zostawiam tam, gdzie naprawdę potrzebna jest współpraca ze starym sprzętem albo starym oprogramowaniem. Na komputerze z UEFI zwykle planuję też osobną partycję EFI, a przy BIOS i GPT pamiętam o małej partycji startowej dla bootloadera. To prowadzi do kolejnego pytania: jak taki układ sensownie rozrysować pod Linuksa, żeby nie komplikować sobie życia bardziej niż trzeba.
Jak ułożyć partycje pod Linuksa bez przesady
Najpraktyczniejszy układ zależy od tego, czy stawiasz system domowy, maszynę roboczą, dual boot czy serwer. Ja zwykle zaczynam od zasady: im mniej realnych potrzeb, tym prostszy układ. Na zwykłym laptopie nie ma sensu mnożyć partycji tylko po to, żeby wyglądało to „profesjonalnie”. Lepiej mieć kilka dobrze dobranych punktów montowania niż sześć małych obszarów, które po roku przestają pasować do sposobu użycia komputera.
| Element | Typowy rozmiar | Kiedy go potrzebujesz | Uwagi praktyczne |
|---|---|---|---|
/boot/efi |
200-500 MiB | Na UEFI | To tu trafiają pliki startowe; bez niej UEFI zwykle nie uruchomi systemu |
/boot |
1 GiB | Gdy chcesz osobny obszar dla kernela i plików rozruchowych | Przy wielu kernelach lub snapshotach 1 GiB daje wygodny zapas |
/ |
40-100 GiB | Zawsze | Tu ląduje sam system i zainstalowane pakiety; dla desktopu 60 GiB bywa wygodnym minimum |
/home |
Reszta dostępnego miejsca | Gdy chcesz oddzielić dane użytkownika od systemu | To dobry wybór, jeśli planujesz reinstalacje albo chcesz łatwiej przenosić dane |
swap |
Zależnie od RAM | Przy braku hibernacji albo jako wsparcie pamięci | Nie kopiuj starego schematu „swap = RAM”; dziś liczy się sposób użycia |
Dla prostego desktopu najczęściej wybieram GPT, /boot/efi, jedną partycję /, opcjonalnie /home i rozsądny swap. Przy 16 GiB RAM bez hibernacji zwykle wystarcza 4-8 GiB swap, a przy mniejszych zasobach warto go zwiększyć. Jeżeli planujesz hibernację, swap musi być większy, bo system zapisuje do niego stan pamięci. W konfiguracjach z LVM albo pełnym szyfrowaniem często zostawiam też prostą, osobną partycję rozruchową, bo bootloader ma wtedy mniej problemów z dostępem do plików.
Jeśli system ma służyć do konkretnych zadań, układ warto lekko zmodyfikować. Na maszynie z wieloma usługami rozważyłbym osobne /var, bo logi, cache i dane kontenerów potrafią zapełnić główną partycję szybciej niż użytkownik to zauważy. Na laptopie z codziennym użyciem zwykle nie komplikuję układu bardziej niż to konieczne. Prosty schemat jest łatwiejszy do utrzymania, a przy awarii daje mniej miejsc, w których coś może pójść nie tak. Mając to ustalone, można przejść do sprawdzenia tego, co już siedzi na dysku.
Jak sprawdzić i bezpiecznie zmieniać układ na już zainstalowanym systemie
Zanim cokolwiek ruszę, sprawdzam układ bez zapisu zmian. Najwygodniej zacząć od kilku komend, które pokazują typ tablicy partycji, systemy plików i punkty montowania:
lsblk --output NAME,FSTYPE,SIZE,MOUNTPOINTS,PARTLABEL
sudo fdisk -l
sudo blkid
lsblk pokazuje strukturę drzewa urządzeń i montowania, fdisk -l ujawnia typ tablicy i rozmiary, a blkid podaje UUID, które później wpisujesz do /etc/fstab. Ja wolę jawnie wskazać kolumny w lsblk, bo dzięki temu od razu widzę to, co naprawdę ma znaczenie. Jeśli planujesz edycję, cfdisk jest wygodny, bo zmiany zapisujesz dopiero na końcu, a nie przy każdej operacji. To zmniejsza ryzyko przypadkowego kliknięcia w zły wolumin.
- Najpierw robię kopię danych, których nie mogę stracić.
- Potem sprawdzam, czy modyfikuję właściwy dysk, zwłaszcza na maszynach z wieloma nośnikami.
- Dopiero później odmontowuję partycje, które chcę zmieniać.
- Na końcu zapisuję zmiany i ponownie weryfikuję, czy system widzi nowy układ tak, jak powinien.
Jeśli partycja ma być przesuwana, a nie tylko tworzona od zera, nie przyspieszam tego na siłę. Przesuwanie zajętego obszaru zawsze niesie większe ryzyko niż zwykłe utworzenie nowego układu, więc backup przestaje być „dobrą praktyką”, a staje się warunkiem wejścia. Gdy już wiesz, jak sprawdzić stan nośnika, pozostaje najważniejsza część: nie popełnić typowych błędów, które robią się kosztowne dopiero po restarcie.
Najczęstsze błędy, które później kosztują najwięcej czasu
Najczęściej widzę te same pomyłki. Pierwsza to zbyt mała partycja systemowa, która po kilku aktualizacjach przestaje wystarczać. Druga to trzymanie wszystkiego w jednym miejscu bez planu awaryjnego, przez co reinstalacja systemu staje się operacją bolesną zamiast rutynową. Trzecia to ignorowanie trybu startu komputera: na UEFI brakuje partycji EFI, a przy starszym BIOS ktoś próbuje na siłę używać układu, który od początku nie pasuje do sprzętu.
- Mylenie nazwy urządzenia, zwłaszcza przy NVMe, gdzie partycje mają postać
nvme0n1p1, a niesda1. - Wybór MBR na dużym nośniku tylko dlatego, że „tak było kiedyś”, mimo że GPT byłby prostszy i bezpieczniejszy.
- Wpychanie
/boottam, gdzie bootloader nie ma do niego wygodnego dostępu, szczególnie przy LVM i szyfrowaniu. - Tworzenie zbyt wielu małych partycji, które po czasie są trudniejsze do utrzymania niż jeden rozsądnie podzielony układ.
- Zmiana układu bez kopii zapasowej, bo „przecież to tylko kilka kliknięć”.
W praktyce najgorsze błędy nie wynikają z braku wiedzy o samych narzędziach, tylko z pośpiechu. Ja zawsze traktuję układ partycji jako część architektury systemu, a nie dekorację. Jeśli coś ma się później skalować, być szyfrowane albo dać się odtworzyć z kopii, to plan trzeba przygotować wcześniej, a nie ratować się po fakcie. Zostaje mi jeszcze jedna rzecz, którą sprawdzam przed ruszeniem tablicy partycji, bo oszczędza najwięcej nerwów.
Co sprawdzam, zanim ruszę tablicę partycji
- Czy komputer startuje w trybie UEFI, BIOS czy w konfiguracji mieszanej.
- Czy mam aktualną kopię danych i wiem, co dokładnie musi zostać zachowane.
- Czy na dysku jest miejsce na przyszłe aktualizacje, snapshoty albo dodatkowe usługi.
- Czy chcę LVM, LUKS albo Btrfs, bo to zmienia sposób myślenia o podziale przestrzeni.
- Czy układ ma wspierać hibernację, a więc wymaga większego swapu.
Jeśli zaczynam od zera, najczęściej wybieram prosty zestaw: GPT, UEFI, mała partycja EFI, rozsądne /, opcjonalne /home i swap dobrany do RAM oraz sposobu pracy. Jeśli system już działa i nie masz konkretnego problemu, nie zmieniam układu tylko po to, żeby był „ładniejszy” na papierze. Dobry układ partycji ma ułatwiać życie, a nie dokładać obowiązków przy każdej aktualizacji i każdej awarii.