ext4

Czy w linux plik SWAP jest lepszy niż partycja wymiany

Ostatnimi czasy, z racji rozwoju technologicznego, mamy do dyspozycji coraz to szybsze komputery, co przekłada się w znacznym stopniu na prędkość wykonywania operacji przez ich systemy operacyjne. Obecnie przeciętnej klasy desktop czy laptop jest już wyposażony w 16G czy nawet 32G pamięci operacyjnej (w niedługim czasie nawet smartfony będą posiadać 12G RAM). Spada zatem zapotrzebowanie wykorzystania dysku twardego jako pamięci RAM. W linux używanie dysku twardego jako rozszerzenie pamięci operacyjnej było i jest w dalszym ciągu realizowane za sprawą przestrzeni wymiany SWAP. Ta przestrzeń wymiany może być zaimplementowana w postaci osobnej partycji dysku twardego albo też jako plik umieszczony w obrębie systemu plików, np. ext4. Część dystrybucji linux'a decyduję się na porzucenie partycji wymiany na rzecz pliku SWAP. Czy taki krok jest uzasadniony i czy korzystając aktualnie z partycji wymiany powinniśmy zmigrować na plik SWAP?

Czym jest Online ext4 Metadata Check w linux'owym LVM

Przeglądając dzisiaj rano logi systemowe wpadł mi w oczy komunikat, którego treść brzmiała mniej więcej tak: e2scrub Volume group "wd_blue_label" has insufficient free space (0 extents): 64 required , po którym z kolei można zanotować e2scrub snapshot FAILED, will not check! oraz Failed to start Online ext4 Metadata Check for /media/Debian . Oczywiście ten punkt montowania to nazwa partycji odnosząca się do jednego z dysków logicznych struktury LVM. Skąd się te błędy wzięły? Przecież jeszcze do niedawna (przez ostatnich parę lat) wszystko z moim linux'em rezydującym na dysku (LUKS+LVM) było w porządku, a teraz nagle takie bardzo niepokojące błędy. Czym jest w ogóle ten e2scrub i czym jest ten cały Online ext4 Metadata Check , który najwyraźniej ma coś wspólnego ze sprawdzaniem systemu plików voluminów logicznych w locie? No i najważniejsze chyba pytanie -- czemu to nie działa jak należy?

Unexpected Inconsistency: Inode has corrupt extent header

Dzisiaj system plików jednej z partycji mojego głównego dysku uległ awarii z niewiadomych przyczyn. Dałbym sobie nawet głowę uciąć, że wszystkie partycje zostały poprawnie odmontowane podczas wyłączania maszyny. Niemniej jednak, z jakiegoś powodu podczas startu systemu, ten wyrzuca szereg komunikatów dotyczących głównego systemu plików, tj. / . Sam komunikat brzmi mniej więcej tak: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY . Oznacza to, że błędy w systemie plików nie są łatwe do naprawy i wymagana jest nasza ingerencja w ten proces. Przy sprawdzaniu systemu plików w poszukiwaniu błędów przy pomocy fsck.ext4 można było dostrzec min. taką wiadomość: Inode 556975 has corrupt extent header . Co ona tak naprawdę oznacza i czy damy radę wybrnąć z tej sytuacji bez szwanku?

Data i czas utworzenia pliku w linux'ie (crtime)

Systemy plików, które wykorzystujemy na partycjach swoich dysków, zawierają metadane opisujące pliki. Domyślnym systemem plików w większości linux'ów (do nich zalicza się też debian) jest EXT4. Gdy listujemy pliki przy pomocy narzędzia ls , jesteśmy w stanie uzyskać szereg informacji opisujących konkretny plik. Mamy tam min. czas ostatniej modyfikacji i-węzła (i-node), czyli tzw. ctime . Narzędzia takie jak stat są w stanie podać również inne czasy, tj. atime (ostatni czas dostępu do pliku) oraz mtime (ostatni czas modyfikacji pliku). Jednak żaden z tych powyższych nie przekłada się na czas utworzenia pliku. Co prawda, po stworzeniu pliku, wszystkie te czasy są ze sobą zsynchronizowane ale po przeprowadzeniu szeregu różnych operacji na tym pliku, problematyczne może być ustalenie pierwotnej daty jego utworzenia. Celem tego artykułu jest pokazanie, jak przy pomocy debugfs uzyskać czas utworzenia dowolnie wskazanego pliku w systemie plików EXT4.

Zmiana identyfikatora UUID

Na forum DUG'a po raz kolejny pojawił się post dotyczący unikalnych identyfikatorów, które są nadawane partycjom dysków twardych. Nie wiem jak sprawa ma się w przypadku windowsów ale linux na podstawie tych numerów UUID (GUID) jest w stanie identyfikować konkretne urządzenia. Czasem się zdarza tak, że dwa dyski czy partycje mają taki sam identyfikator, co prowadzi zwykle do problemów. Kolizja numerów identyfikacyjnych może być wynikiem pozostałości po procesie produkcyjnym ale może także powstać za sprawą klonowania nośnika za pomocą narzędzia dd . Tak czy inaczej, przydałoby się wiedzieć jak ustalić, poprawnie wygenerować czy też zmienić UUID wszędzie tam, gdzie jest on wykorzystywany i o tym będzie ten wpis.

Zmiana rozmiaru partycji EXT4

Jeśli jeszcze nie dokonaliśmy migracji systemu plików z EXT2/3 na EXT4, to powinniśmy rozważyć tę kwestię z przyczyn czysto praktycznych. W tym wpisie nie będziemy sobie głowy zawracać migracją między poszczególnymi wersjami systemu plików z rodziny EXT, a raczej skupimy się na tym jak zmienić rozmiar partycji, której systemem plików jest właśnie EXT4. Bawienie się rozmiarem partycji w tym przypadku niczym zbytnio się nie różni w stosunku do omawianego wcześniej systemu plików NTFS. Będziemy wykorzystywać tylko nieco inne narzędzia.

Jak odzyskać usunięte z dysku pliki

Całkowite usuwanie plików (shred) jak i zerowanie całych nośników ma na celu nieodwracalne zniszczenie danych. W tych podlinkowanych artykułach próbowaliśmy zatrzeć ślady po skasowanych plikach. W tym wpisie zaś prześledzimy sobie co tak naprawdę się dzieje po utworzeniu i skasowaniu pliku, a także spróbujemy odzyskać te z nich, które już nie istnieją w naszym systemie. Ten artykuł będzie dotyczył jedynie systemu plików z rodziny ext , głównie ext4 .

Migracja systemu plików ext2 i ext3 na ext4

Dyski twarde są w stanie pomieścić setki gigabajtów danych. Ilość informacji, które jesteśmy w stanie przechować na pojedynczym nośniku, rośnie w zastraszającym tempie. Rozwój technologii nie jest jedynym polem gdzie prowadzone są prace nad nowymi rozwiązaniami poprawiającymi szereg aspektów pracy tych urządzeń. Innym polem jest sfera programowa, która w przypadków dysków twardych w dużej mierze dotyczy systemu plików. Albowiem każda powierzchnia, na której mają być przechowywane dane, potrzebuje odpowiedniej struktury, którą również można usprawnić. Wobec czego, ten domyślny system plików w linux'ie, tj. ext , przeszedł szereg modyfikacji i pojawiły się wersje ext2 , ext3 i ext4 . Jeśli jakaś partycja dysku twardego zawiera starszą wersję systemu plików, powinniśmy dokonać migracji na jego nowszy odpowiednik. W przypadku migracji z ntfs na ext4 (czy też odwrotnie), nieunikniona jest utrata danych. Czy w przypadku migracji z systemu plików ext2 i ext3 na ext4 również musimy zgrywać wszystkie dane na osobny nośnik by przeformatować odpowiednio taki dysk czy partycję? Okazuje się że nie musimy i możemy dokonać takiej migracji bez obaw o utratę danych i w tym wpisie postaramy się ten zabieg przeprowadzić.

Kompaktowanie katalogów w systemie plików ext4

Jakiś czas temu pewien człowiek miał dziwaczny problem. Jak możemy wyczytać w przytoczonym linku, system tego użytkownika lekko mówiąc nie zachowywał się tak jak powinien. Objawiało się to przez dość ekstensywne wykorzystywanie pamięci operacyjnej RAM przy zwykłym listowaniu plików via ls w pewnych określonych katalogach. Struktura systemu plików zdaje się być porządku, bo program fsck nie zwraca żadnych błędów. Zatem w czym problem?

Opcja extents w systemach plików ext4

Dziś postanowiłem sprawdzić jak wygląda struktura plików mojego dysku. Chodzi oczywiście o ich fragmentację. Zgodnie z tym co pokazał mi fsck , pofragmentowanych plików jest 350. Po zapuszczeniu defragmentacji via e4defrag ilość tych plików spadła do nieco ponad 100 i jeśli by się przyjrzeć procesowi defragmentacji, to można było zauważyć linijki mające extents: 100 -> 10 . Wychodzi na to, że plik dalej jest w kawałkach i nie idzie go zdefragmentować. Jak rozumieć taki zapis?