Mam macierz programową RAID 5 na Linuksie. 5 dysków. Do tej pory były to dyski 2 TB, ale ostatnio podmieniłem na dyski 4TB. Podmiany dokonywałem kolejno wypinając dysk 2 TB i wpinając 4TB. Macierz odbudowywała się i wymieniałem następny dysk. Po wymianie ostatniego dysku i odbudowaniu macierzy wykonałem polecenie mdadm --grow /dev/md0 --size=max
Macierz przebudowała się bezproblemowo i zwiększyła swój rozmiar dwukrotnie, tak jak oczekiwałem.
Pozostało rozszerzyć partycję. Niestety, nie mogę nawet uruchomić fsck, bo urządzenie jest zajęte, pomimo, że partycja jest odmontowana. Odpowiednio odfiltrowany wynik polecenia lsof jest taki: jbd2/md0- 1087 root cwd DIR 8,1 4096 2 / jbd2/md0- 1087 root rtd DIR 8,1 4096 2 / jbd2/md0- 1087 root txt unknown /proc/1087/exe
Wygląda na to, że odbudowuje się dziennik, ale to trwa już ponad 50 godzin! Czy to jest normalne?
Czy można jakoś bezpiecznie przerwać tę operację?
Macierz na razie działa, bo bezproblemowo dała się zamontować, tyle, że ma stary rozmiar partycji.
Spodziewałeś się, że ponad 20TB będzie budowało się godzinę? Daj czas jeśli nie chcesz stracić danych.
Jak masz utworzone urzadzenie md0? Z partycji, dysków? Zwiększenie wolumenu, to nie tylko zwiększenie FS. Na tej macierzy masz jakąś partycję. Ta partycja ma wielkość poprzedniej partycji. Partycję trzeba usunąć, bez ruszania FS, utworzyć nową o wielkości jakiej potrzebujesz. Zrobić fsck i resize dopiero.
Macierz mam złożoną z dysków, na których została założona 1 partycja Linux RAID.
Na macierzy mam jedną partycję EXT4.
To nieprawda, że partycję trzeba usunąć.Trzeba ją tyko rozszerzyć.
Robiłem już to przy przechodzeniu z dysków 1TB na 2 TB i wszystko się udało bez żadnych problemów i bez utraty danych.
Zrobiłem kolejno tylko: e2fsck -f /dev/md0 resize2fs /dev/md0 e2fsck -f /dev/md0
Ale wtedy nie czekałem na odbudowanie dziennika.
Dlatego teraz jestem trochę zaskoczony.
Gwoli ścisłości: teraz macierz ma rozmiar dokładnie 14903.59 GiB 16002.61 GB
Zamieszałeś trochę. Dlatego pytałem jak to jest skonstruowane. Jeśli urządzenie blokowe jest już powiększone, to zostaje tylko rozszerzenie fs. W każdym razie zrób backup. To, że wtedy nic się nie stalo, nie znaczy, że teraz nic się nie może wydarzyć.
Backup to rzecz pierwsza. Ale na razie nie mogę nic zdziałać w kierunku rozszerzenia fs.
Macierz po poskładaniu jest zajęta. Nawet jeśli md0 nie jest zamontowana.
Właśnie przed chwilą sprawdzałem.
Boję się, że czeka mnie przeformatowanie. Mam jeszcze jeden pomysł, aby zatrzymać księgowanie (podobno tune2fs to może zrobić) i dopiero wtedy rozszerzyć system plików. Ale nie wiem, czy to bezpieczna operacja. Na razie zaczynam robić kopie zapasowe. Około 6 TB danych.
Jakieś inne opcje?
Znalazłem jeszcze taka poradę:
Teraz mi przyszła do głowy jedna rzeczy. Jaką masz tablicę partycji na tym md0?
Czego nie rozumiesz, to jest to o czym pisałem? Jeśli masz raid z partycji lub partycję na RAID, musisz ją usunąć i stworzyć nową, bez ruszania FSa. GParted robi dokładnie to samo, gdy spojrzysz w szczegóły operacji. Dopiero potem możesz robić powiększenie FSa.
Wracamy do tematu. Stoję w martwym punkcie. Cały czas trwa księgowanie i mimo próby wyłączenia poleceniem tune2fs -O ^has_journal /dev/md0
użycie e2fsck daje komunikat: e2fsck 1.45.2 (27-May-2019) /dev/md0 jest w użyciu.
Tak jak pisałem na początku partycja to EXT4
Pozostała mi opcja usunąć i utworzyć partycję, ale nie wiem czy to pomoże.
Po uruchomieniu fdisk dostałem taki komunikat: Stara sygnatura ext4 będzie usunięta przy poleceniu zapisu.
Urządzenie nie zawiera żadnej znanej tablicy partycji. Rozmiar tego dysku to 14,6 TiB (16002605645824 bajtów). DOS-owy format tablicy partycji nie może być używany dla dysków na wolumenach większych niż 2199023255040 bajtów dla 512-bajtowych sektorów. Należy użyć formatu tablicy partycji GUID (GPT).
Utworzono nową etykietę dysku DOS z identyfikatorem dysku 0xd5cc3d56.
Wygląda na to, że muszę założyć partycję GPT i przywracać dane z kopii.
System plików pewnie przepadnie.
Sytuacja już opanowana, ale napiszę co i jak było.
Założyłem partycję GPT i włączyłem naprawę systemu plików. Znalazło tysiące błędów. Naprawiało… tak z półtorej godziny. W końcu przestało naprawiać. Po kolejnej godzinie, kiedy nic się nie działo, ubiłem proces zdecydowany sformatować partycję na nowo.
Zrestartowałem serwer (system jest na oddzielnej partycji) i nie mam pojęcia co się działo przez ok 20 minut, bo system nie wstawał. A robiłem to zdalnie.
Kiedy już się połączyłem z serwerem zauważyłem, że macierz zamontowała się automatycznie. Wszystkie dane były!
Odmontowałem macierz, ale w dalszym ciągu nie mogłem rozszerzyć systemu plików, ani nawet włączyć sprawdzania. Tak jak poprzednio pracowało księgowanie.
Zamontowałem macierz na powrót i sprawdziłem czy wszystko działa.
Ponieważ wszystko zdawało się normalnie pracować (a na tej partycji miałem między innymi: home, dane z poczty w sieci LAN, bazy Firebird, bazy MSSQL), postanowiłem zająć się sprawą w innym czasie, licząc na to, że księgowanie w końcu zwolni system plików.
Jedyne co się zmieniło to wyświetlanie wolnego miejsca pod Windows. Pokazywało tak, jakby rzeczywiście dysk sieciowy miał 14,4 TB, choć w rzeczywistości system plików miał 7,2TB.
Kiedy już zrestartowałem system na konsoli serwera okazało się dlaczego tak długo nie wstaje. Sprawdzał macierz przez ponad 15 minut, ale nie naprawiał błędów. A było ich tysiące. Niestety, włączenie fsck z naprawą okazało się niemożliwe. System plików zajęty. Miałem już dość kombinowania.
Zrobiłem kopie i sformatowałem partycję na nowo. Przywróciłem dane.
Koniec.
lsblk anomizuje dane a tego nie chcemy…