Jak zmienić rozmiar partycji ext4 poza limit 16 TB?

Podczas próby zmiany rozmiaru i starej partycji ext4, która została utworzona bez flagi 64-bitowej, resize2fs 1.42 nie powiedzie się, jeśli nowy rozmiar jest większy lub większy niż 16 TB.

$ resize2fs -p /dev/mapper/target-device
resize2fs: New size too large to be expressed in 32 bits

Nie chcę kopiować plików na zewnętrzny nośnik. Nie chcę też ryzykować utraty danych. Jak mogę bezpiecznie zmienić rozmiar woluminu?

Próbujesz zmienić rozmiar systemu plików, który został utworzony, zanim -O 64bitopcja stała się domyślna. Możliwe jest uaktualnienie systemu plików ext do adresów 64-bitowych, co pozwala na znacznie większy wolumen (1024 PiB zamiast 16 TiB).

Zakładając, że nazywa się Twoje urządzenie docelowe /dev/mapper/target-device, musisz to zrobić:

Wymagania wstępne

1. Ten rozmiar woluminu musi być zabezpieczony przez RAID. Regularne błędy dysków będzie działać szkodliwie inaczej.
2. Mimo to RAID nie jest kopią zapasową . Kosztowności musisz przechowywać także w innym miejscu.
3. Najpierw zmień rozmiar i sprawdź wszystkie otaczające woluminy (tablice partycji, szyfrowanie, lvm).
4. Po zmianie sprzętowej konfiguracji RAID linux może natychmiast potwierdzić nowy maksymalny rozmiar. Sprawdź $ cat /proc/partitionsi uruchom ponownie, jeśli to konieczne.

Użyj najnowszego stabilnego jądra i e2fsprogs

1. Upewnij się (sprawdź uname -r), czy używasz jądra, które poprawnie obsługuje 64-bitowe systemy plików ext4 - chcesz użyć 4.4.xjądra lub nowszego (domyślnie Ubuntu 16 i wyżej).

2. Zdobądź e2fsprogs co najmniej wersji 1.43

   • Ubuntu 16.04(2016-04-21) został wydany z e2fsprogs 1.42.12(2014-08-25)
   • e2fsprogs 1.43 (2016-05-17) to pierwsze wydanie zdolne do aktualizacji rozmiaru adresu extfs.
   • Ubuntu 18.04(2018-04-26) wysyłany z e2fsprogs 1.44.x(dobrze!)

Jeśli jesteś włączony 16.04i nie możesz dokonać aktualizacji do nowszej wersji Ubuntu, musisz włączyć obsługę pakietu źródłowego i ręcznie zainstalować nowszą wersję:

$ resize2fs
# if this  prints version 1.43 or above, continue to step 1
$ sudo apt update
$ sudo apt install git
$ sudo apt build-dep e2fsprogs
$ cd $(mktemp -d)
$ git clone -b v1.44.2 https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git e2fsprogs && cd e2fsprogs
$ ./configure
$ make
$ cd resize
$ ./resize2fs
# this should print 1.43 or higher
# if this prints any lower version, panic
# use `./resize2fs` instead of `resize2fs` for the rest of the steps

Zmień rozmiar

Krok 1: Prawidłowo zamontuj system plików

$ sudo umount /dev/mapper/target-device

Krok 2: Sprawdź system plików pod kątem błędów

$ sudo e2fsck -fn /dev/mapper/target-device

Krok 3: Włącz obsługę 64-bitową w systemie plików

Skonsultuj się man tune2fsi man resize2fs- możesz zmienić niektóre flagi systemu plików.

$ sudo resize2fs -b /dev/mapper/target-device

W typowym HDD RAID zajmuje to 4 minuty dużego obciążenia IO i procesora.

Krok 4: Zmień rozmiar systemu plików

$ sudo resize2fs -p /dev/mapper/target-device

Jeśli nie podasz rozmiaru w wierszu poleceń, resize2fs zakłada „powiększ się do całej dostępnej przestrzeni” - zwykle jest to dokładnie to, czego chcesz. -pFlag włączony paski postępu - ale tylko tych wyświetlać po początkowych etapach.

W typowym HDD RAID zajmuje to 4 minuty dużego obciążenia IO i procesora.

Zweryfikuj ponownie

Sprawdź ponownie system plików

$ sudo e2fsck -fn /dev/mapper/target-device

e2fsck nowszych wersji może sugerować naprawę znaczników czasu lub rozszerzanie zakresu drzew, które poprzednie wersje źle obsługiwały. Nie oznacza to żadnego poważnego problemu i możesz zdecydować się naprawić go teraz lub później.

Jeśli wystąpią błędy, nie panikuj i nie próbuj zapisywać na woluminie; skonsultuj się z kimś, kto ma rozległą wiedzę na temat systemu plików, ponieważ dalsze operacje prawdopodobnie zniszczą dane!

Jeśli nie wystąpią żadne błędy, zainstaluj ponownie urządzenie:

$ sudo mount /dev/mapper/target-device

Sukces!

Nie będziesz potrzebował żadnej e2fsprogs innej niż Ubuntu, aby kontynuować działanie zaktualizowanego systemu plików - jądro obsługuje je już od dłuższego czasu. Konieczne było tylko zainicjowanie aktualizacji.

Dla porównania, podobny komunikat o błędzie zostanie wydrukowany przez mke2fs, jeśli zostanie poproszony o utworzenie ogromnego urządzenia z nieodpowiednimi opcjami:

$ mke2fs -O ^64bit /dev/huge
mke2fs: Size of device (0x123456789 blocks) is too big to be expressed in 32 bits using a blocksize of 4096.

Zdarzyło mi się to niedawno z Ubuntu 18.04, który został zaktualizowany po pierwszej instalacji z Ubuntu 16.04 ... Macierz pamięci (/ dev / sdb) została początkowo podzielona na dwie partycje o wielkości 14 TB, a to dlatego, że chce się powiększyć pierwsza partycja do 28 TB, w której wystąpił problem.

Nie musiałem pobierać nowej wersji resize2fs, ponieważ była to najnowsza wersja.

# resize2fs 
resize2fs 1.44.1 (24-Mar-2018)

Jedynym problemem była konwersja 64-bitowej partycji 1, która została sformatowana w 32 bitach ... Zamiast zapraszania czytelnika do zapoznania się z dokumentacją tune2fs (jak sugeruje Anx), proponuję prawdziwy przykład!

# tune2fs -O 64bit /dev/sdb1
tune2fs 1.44.1 (24-Mar-2018)
Please run "resize2fs -b /dev/sdb1" to enable 64-bit mode.

# resize2fs -b /dev/sdb1
resize2fs 1.44.1 (24-Mar-2018)
Convert the file system to 64 bits.
The file system on /dev/sdb1 now has a size of 3662109119 blocks (4k).

Wreszcie powiększamy partycję dysku!

# resize2fs /dev/sdb1
resize2fs 1.44.1 (24-Mar-2018)
Resizing the file system on /dev/sdb1 to 7324303099 (4k) blocks.
The file system on / dev / sdb1 now has a size of 7324303099 blocks (4k).