Dobrze zaplanowane partycjonowanie dysku ułatwia instalację, późniejsze aktualizacje i odzyskiwanie systemu po awarii. W praktyce największą różnicę robi nie sama liczba partycji, tylko to, czy dobierzesz właściwą tablicę, sensowny rozmiar dla EFI, rozsądną przestrzeń dla systemu i miejsce na dane. Poniżej pokazuję, jak podejść do tego bez zbędnej komplikacji i jak uniknąć błędów, które później kosztują czas albo dane.
Najważniejsze decyzje zapadają przed formatowaniem, nie po nim
- W większości współczesnych komputerów lepiej sprawdza się GPT niż MBR, zwłaszcza przy UEFI i dyskach większych niż 2 TiB.
- Na typowym Linuksie często wystarcza jedna partycja systemowa, a swap w formie pliku, jeśli nie potrzebujesz hibernacji.
- Osobne /home ma sens głównie wtedy, gdy często reinstalujesz system albo chcesz mocno oddzielić dane od systemu.
- Przed zmianami zawsze sprawdzam nośnik poleceniem `lsblk` i robię kopię zapasową, nawet jeśli operacja wydaje się prosta.
- W systemach UEFI potrzebna jest partycja EFI, a w układach z szyfrowaniem i GRUB-em trzeba wcześniej przemyśleć dostęp do /boot.
Co naprawdę robi podział dysku i kiedy ma sens
Partycja to po prostu wydzielony fragment nośnika, który system widzi jako osobny obszar. Ja zwykle traktuję ją nie jako cel sam w sobie, tylko jako narzędzie do porządkowania systemu: możesz oddzielić system od danych, ustawić osobny obszar rozruchowy, przygotować miejsce na swap albo uprościć reinstalację bez ruszania plików użytkownika.
To rozwiązanie ma sens szczególnie wtedy, gdy zależy ci na przewidywalności. Osobny system i dane ułatwiają backup, a w środowisku Linux przydają się też przy szyfrowaniu, snapshotach i dual boot. Z drugiej strony zbyt duża liczba małych partycji potrafi bardziej przeszkadzać niż pomagać, bo później jedna się zapycha, druga zostaje pusta, a trzecią trudno rozbudować bez przenoszenia danych.
W praktyce najczęściej pytanie nie brzmi „czy dzielić”, tylko „jak bardzo dzielić”. I właśnie od tego zależy wybór tablicy partycji, więc w następnym kroku przechodzę do różnicy między GPT i MBR.
GPT czy MBR i co naprawdę ma znaczenie dziś
Jeśli komputer ma UEFI, a dysk nie jest zabytkowy, najczęściej wybieram GPT. To obecny standard, który lepiej znosi duże nośniki, obsługuje więcej partycji i lepiej współgra z nowoczesnym startem systemu. MBR nadal działa, ale traktuję go jako wybór dla starszego sprzętu albo konkretnych wymagań kompatybilności.
| Cecha | GPT | MBR |
|---|---|---|
| Typowe zastosowanie | Nowe komputery, UEFI, Linux, dual boot | Starszy BIOS, starszy sprzęt, awaryjne scenariusze |
| Limit rozmiaru | Bez praktycznego ograniczenia dla domowych zastosowań | Około 2 TiB |
| Liczba partycji | Zwykle do 128 | 4 podstawowe, ewentualnie więcej przez partycję rozszerzoną |
| UEFI | Naturalny wybór | Może działać, ale bywa mniej wygodny i mniej przewidywalny |
| Obsługa starszych systemów | Dobra, ale zależna od firmware i bootloadera | Najszersza zgodność ze starym BIOS-em |
Jeżeli mam jeden prosty wniosek, to taki: na współczesnym sprzęcie GPT daje mniej kompromisów. MBR wybieram tylko wtedy, gdy naprawdę muszę. Kiedy wybór tablicy jest już jasny, można dobrać sensowny układ samych partycji i tutaj łatwo przesadzić albo uprościć temat za mocno.
Jak dobrać układ partycji do typowego Linuksa
Nie ma jednego wzoru, który pasuje do każdego. Ja zwykle patrzę na trzy rzeczy: czy system ma startować przez UEFI, czy potrzebujesz szyfrowania oraz czy planujesz często reinstalować system. Dopiero potem dobieram rozmiary i liczbę partycji.
| Scenariusz | Przykładowy układ | Dlaczego to działa |
|---|---|---|
| Typowy laptop lub desktop | ESP 512 MiB, root 50-80 GiB, reszta jako dane lub /home, swap jako plik | Mało komplikacji, łatwa administracja, wygodne aktualizacje |
| System z hibernacją | ESP 512 MiB, root 50-80 GiB, swap o rozmiarze co najmniej zbliżonym do RAM | Hibernacja wymaga przewidywalnego obszaru wymiany |
| Dual boot z innym systemem | Wspólna ESP 512 MiB-1 GiB, osobny root Linuksa, ewentualnie osobne /home | Nie duplikujesz infrastruktury rozruchowej |
| System z Btrfs albo LVM | ESP + jedna większa partycja na wolumin lub kontener logiczny | Lepsza elastyczność niż wiele drobnych partycji |
| Komputer roboczy z częstymi reinstalacjami | ESP, root, osobne /home | System można wymienić bez ruszania danych użytkownika |
W systemach UEFI partycja EFI jest obowiązkowa do uruchomienia komputera, więc tu nie ma miejsca na zgadywanie. Jeśli planujesz pełne szyfrowanie, osobny /boot albo dobrze przemyślany układ bootloadera stają się ważniejsze niż zwykle. Gdy układ masz już w głowie, warto przejść do technicznego wykonania i zrobić to w kolejności, która minimalizuje ryzyko.
Jak wykonać podział bezpiecznie krok po kroku
Najpierw sprawdzam, z którym nośnikiem naprawdę pracuję. W Linuksie błędy zwykle nie wynikają z samego narzędzia, tylko z tego, że ktoś pomylił `/dev/sda` z innym dyskiem albo nie zauważył, że laptop pokazuje nośnik NVMe jako `/dev/nvme0n1`. Dlatego przed jakąkolwiek zmianą uruchamiam `lsblk -f`, `blkid` albo `fdisk -l`.
- Robię kopię danych, które mają znaczenie. To nie jest formalność, tylko warunek wejścia.
- Sprawdzam, czy partycje nie są zamontowane i czy pracuję na właściwym dysku.
- Tworzę tablicę GPT, jeśli sprzęt jest nowoczesny, a następnie zakładam partycje od granicy 1 MiB.
- Formatuję partycje zgodnie z ich rolą: FAT32 dla EFI, ext4 lub Btrfs dla systemu, swap tylko tam, gdzie faktycznie jest potrzebny.
- Montuję je i wpisuję do `/etc/fstab` identyfikatory UUID albo PARTUUID, a nie nazwy urządzeń, które mogą się zmienić.
lsblk -f
sudo fdisk /dev/nvme0n1
# g -> GPT, n -> nowa partycja, w -> zapis zmian
sudo mkfs.fat -F32 /dev/nvme0n1p1
sudo mkfs.ext4 /dev/nvme0n1p2
sudo mkswap /dev/nvme0n1p3
sudo swapon /dev/nvme0n1p3Do szybkiej pracy lubię `fdisk`, bo jest prosty i dobrze obsługuje GPT oraz MBR. Gdy potrzebuję bardziej czytelnego widoku albo pracy na większej ilości partycji, sięgam po `parted` albo graficzny `GParted`, ale zasada pozostaje ta sama: najpierw identyfikacja, potem operacja, nigdy odwrotnie. Kiedy już wiesz, jak to zrobić, warto przejść przez błędy, które pojawiają się najczęściej.
Najczęstsze błędy, które psują cały plan
Największy błąd to brak kopii zapasowej przed zmianą rozmiaru istniejących partycji. Nawet jeśli narzędzia są dojrzałe, każda operacja na tabeli partycji niesie ryzyko, a ryzyko rośnie, gdy pracujesz na już używanym systemie.
- Mylenie dysku docelowego z innym nośnikiem, zwłaszcza przy kilku SSD i pendrive’ach podpiętych jednocześnie.
- Tworzenie zbyt wielu małych partycji, które trudno później rozbudować i łatwo zapchać.
- Brak partycji EFI w instalacji UEFI albo zły system plików na tej partycji.
- Start partycji nieodpowiadający granicy 1 MiB, co potrafi pogorszyć wydajność i komplikować pracę z niektórymi układami.
- Zakładanie, że swap zawsze musi być osobną partycją, mimo że na wielu komputerach wystarczy swap file.
- Planowanie hibernacji bez odpowiednio dużego obszaru wymiany.
Osobna pułapka pojawia się przy szyfrowaniu. Jeśli zaszyfrujesz wszystko bez przemyślenia kolejności startu, bootloader może nie mieć dostępu do tego, czego potrzebuje na bardzo wczesnym etapie uruchamiania. Dlatego przy bardziej złożonych układach lepiej myśleć o architekturze, a nie tylko o rozmiarach. To prowadzi wprost do pytania, kiedy zamiast mnożyć partycje lepiej sięgnąć po LVM albo Btrfs.
Kiedy lepiej postawić na LVM albo Btrfs zamiast mnożyć partycje
Ja coraz rzadziej tworzę osobne partycje „na wszelki wypadek”. Jeśli system ma być elastyczny, lepiej często sprawdza się jedna większa partycja plus warstwa logiczna, taka jak LVM, albo układ oparty o Btrfs z podwolumenami. Dzięki temu można łatwiej zmieniać rozmiary, robić snapshoty i porządkować system bez fizycznego przepinania granic między partycjami.
| Rozwiązanie | Największa zaleta | Największy minus |
|---|---|---|
| LVM | Łatwa zmiana rozmiarów i sensowna elastyczność w zarządzaniu woluminami | Dodatkowa warstwa do zrozumienia i administracji |
| Btrfs | Snapshoty, podwolumeny i wygodna organizacja systemu bez nadmiaru partycji | Wymaga odrobiny dyscypliny i wiedzy o subvolumach |
| Klasyczne partycje | Przejrzystość i prostota na poziomie firmware oraz instalatora | Trudniej później korygować rozmiary bez migracji danych |
W praktyce nie chodzi o to, żeby zawsze wybierać najbardziej zaawansowaną opcję. Chodzi o to, żeby nie płacić złożonością za efekt, którego w ogóle nie potrzebujesz. Jeśli nie planujesz snapshotów, szybkich rollbacków i częstego przesuwania przestrzeni między obszarami, klasyczny układ może być w pełni wystarczający. Gdy znasz już kompromisy, zostaje ostatnia rzecz: sensowny wzór, który najczęściej polecam na współczesnym komputerze.
Układ, który najczęściej polecam na współczesnym komputerze
Jeśli miałbym wybrać jeden bezpieczny, przewidywalny wariant dla laptopa albo domowego peceta, postawiłbym na GPT, partycję EFI 512 MiB, root 60 GiB i resztę przestrzeni na dane albo /home. Przy braku hibernacji swap jako plik zwykle wystarczy, a cały układ pozostaje prosty do utrzymania i łatwy do odtworzenia po awarii.
Gdy masz dysk 512 GB lub większy, taki schemat daje dobry balans między wygodą a porządkiem. Jeśli pracujesz na wielu systemach, dołóż współdzieloną partycję EFI zamiast tworzyć kolejne kopie tego samego elementu. Jeśli szyfrowanie jest ważne, zaplanuj je od początku, bo późniejsze dokładanie go do nieprzemyślanego układu zwykle oznacza dodatkową migrację. Właśnie taki prosty, świadomy układ najczęściej wygrywa z nadmiernym rozdrabnianiem przestrzeni.
Jeżeli mam zostawić jedną praktyczną myśl, to tę: nie projektuj układu dysku pod teoretycznie „idealny porządek”, tylko pod realne potrzeby, sprzęt i sposób używania systemu. Dobrze dobrane partycje mają pomagać w utrzymaniu Linuksa, a nie zamieniać zwykłą instalację w administracyjny labirynt.
