System-Plików on Morfitronik

TRIM/UNMAP w dyskach SSD podłączonych via adapter USB-SATA na linux

Mikhail Morfikov — Sun, 16 Jun 2024 16:30:00 +0200

Jakiś czas temu opisywałem jak na Debianie włączyć obsługę mechanizmu TRIM (realizowanego przez polecenie fstrim ) na podpiętych do komputera dyskach SSD. Problem w tym, że dyski SSD, z którymi będziemy wchodzić w interakcję, nie zawsze będą podłączane do dedykowanych portów SATA/mSATA. Jak zachowa się zatem nasz linux, gdy będziemy chcieli podłączyć po portu USB zewnętrzny dysk SSD? Przez zewnętrzny dysk USB nie mam na myśli dedykowanych zewnętrznych dysków USB, bo te raczej nie powinny sprawiać kłopotów. Chodzi mi bardziej o wewnętrzne dyski SSD (np. ze starego laptopa), które zamkniemy w dedykowanej obudowie USB, lub też będziemy taki dysk podłączać na krótko za pomocą adaptera USB-SATA. W takich przypadkach zwykle kernel linux'a nie odważy się włączyć wsparcia dla TRIM dla nośników SSD i tak właśnie się stało w przypadku mojego nowo zakupionego dysku od Goodram, a konkretnie jest to model SSDPR-CX400-02T-G2 , który to został podłączony do portu USB3 mojego Raspberry PI (i Debiana) przy pomocy kabelka USB-SATA (Unitek USB3.1 USB-A to 2.5" SATA6G). Przez kilka miesięcy dysk sprawował się bez zarzutu ale ostatnio przy próbie wgrania na niego danych (przez sieć), transfer spadł do dosłownie pojedynczych MiB/s. Poszukałem trochę informacji i okazało się, że dla tego typu nośników trzeba ręcznie włączyć TRIM, o ile będzie to w ogóle możliwe.

Trim/discard przy LUKS/LVM na dysku SSD pod Debian linux

Mikhail Morfikov — Fri, 15 Dec 2023 17:00:00 +0100

Z okazji zbliżającego się końca roku, postanowiłem nieco ogarnąć swojego Debiana, tj. postawić go na nowo. Jakby nie patrzeć 4 lata korzystania z tego linux'a z włączonymi gałęziami unstable i experimental sprawiło, że trochę syfu się nazbierało. Nie chciałem też czyścić całego kontenera LUKS czy samej struktury LVM z systemowymi voluminami logicznymi na starym dysku HDD, bo zainstalowany tam system zawsze może się do czegoś przydać, np. do odratowania tego nowego linux'a. Dlatego też postanowiłem zakupić niedrogi dysk SSD (MLC, używany) i to na nim postawić świeżego Debiana z wykorzystaniem narzędzia debootstrap. Sama instalacja linux'a na dysku SSD nie różni się zbytnio od instalacji na dysku HDD, za wyjątkiem skonfigurowania w takim systemie mechanizmu trim/discard. Standardowi użytkownicy linux'a nie muszą zbytnio nic robić, aby ten mechanizm został poprawnie skonfigurowany. Sprawa się nieco komplikuje, gdy wykorzystywany jest device-mapper, który mapuje fizyczne bloki urządzenia na te wirtualne, np. przy szyfrowaniu dysku z wykorzystaniem LUKS/dm-crypt, czy korzystaniu z voluminów logicznych LVM. Dlatego też postanowiłem przyjrzeć się nieco bliżej zagadnieniu konfiguracji mechanizmu trim/discard na dysku SSD w przypadku zaszyfrowanego systemu na bazie LUKS+LVM.

Analiza systemu plików EXT4 pod kątem formatowania większych dysków pod linux

Mikhail Morfikov — Sun, 25 Jul 2021 18:40:00 +0200

Zapewne każdy użytkownik linux'a tworzył na dysku HDD/SSD partycje sformatowane systemem plików EXT4. Prawdopodobnie też zastanawiało nas pytanie odnośnie ilości zajmowanego miejsca przez strukturę samego systemu plików, zwłaszcza w przypadku dysków o sporych rozmiarach (setki GiB, czy nawet kilka TiB). Jako, że musiałem ostatnio zmigrować kolekcję filmów ze strych dysków na jeden większy, który miał zostać podłączony pod Raspberry Pi z działającym Kodi na bazie LibreELEC, to przy okazji postanowiłem ten dysk sformatować w taki sposób, w jaki powinno się do tego zadania podchodzić wiedząc, że ma się do czynienia z dużym dyskiem, na którym będą przechowywane głównie duże pliki. Celem tego artykułu jest pokazanie jakie błędy przy tworzeniu systemu plików EXT4 można popełnić przez posiadanie niezbyt wystarczającej wiedzy z jego zakresu, oraz jak te błędy wyeliminować przed rozpoczęciem korzystania z tak nie do końca poprawnie przygotowanego do pracy dysku twardego

Czy w linux plik SWAP jest lepszy niż partycja wymiany

Mikhail Morfikov — Fri, 22 Mar 2019 16:23:42 +0000

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

Mikhail Morfikov — Sun, 17 Mar 2019 19:10:30 +0000

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

Mikhail Morfikov — Fri, 01 Jul 2016 14:27:57 +0000

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)

Mikhail Morfikov — Tue, 07 Jun 2016 17:07:54 +0000

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.

Sparse files (rozrzedzone pliki)

Mikhail Morfikov — Thu, 02 Jun 2016 16:42:26 +0000

Każdy system plików opiera się na blokach danych. Standardowo taki blok w systemie plików EXT4 ma 4 KiB (8 x 512 bajtów). Za każdym razem, gdy tworzymy jakiś plik na dysku, alokowana jest pewna część bloków, na których ten plik ma zostać zapisany. Te większe pliki rezerwują więcej bloków, choć nie zawsze są to bloki ciągłe. W taki sposób, plik o rozmiarze 10 GiB okupowałby dokładnie tyle miejsca na dysku ile sam waży. Niemniej jednak są pewne pliki, które może i ważą te 10 GiB ale system plików postrzega je tak jakby miały 100 MiB czy 200 MiB, w zależności od tego ile "faktycznie" taki plik zajmuje miejsca. Jak to możliwe? Pliki, o których mowa, to tzw. "rozrzedzone pliki" (Sparse files). Taki plik składa się z szeregu bloków pustych (mających same zera), których nie trzeba zapisywać na dysk. Zamiast tego, można jedynie zapisać metadane w strykturze systemu plików, które będą opisywać te puste bloki. Poniższy artykuł ma na celu pokazać do czego takie pliki sparse mogą nam się przydać i jak z nich korzystać.

Zmiana rozmiaru katalogu /tmp/ pod OpenWRT

Mikhail Morfikov — Wed, 27 Apr 2016 18:24:12 +0000

OpenWRT ma w swoich repozytoriach całe mnóstwo pakietów. By móc je zainstalować, potrzebne jest nam miejsce na flash'u routera. Ten z kolei nie jest zbyt duży, często nie przekracza 16 MiB. Podczas pracy, system operacyjny routera przeprowadza cały szereg operacji. Część z nich generuje jakieś dane, np. tworzone są pliki konfiguracyjne, generowane statystyki czy pobierane z internetu pliki w celu dalszego ich przetworzenia. Zwykle są to pliki, które wędrują do katalogu /tmp/ . Gdybyśmy chcieli zapisać wszystkie te informacje na flash'u routera, to zabrakłoby nam zwyczajnie miejsca. Inną kwestią są problemy związane z zapisem samego flash'a, który ulega zużyciu. Dlatego też, szereg operacji zapisu został przeniesiony do pamięci operacyjnej RAM. W ten sposób mamy do wykorzystania nieco więcej miejsca ale standardowo nie więcej niż 50% wielkości pamięci operacyjnej. Wielkość tego RAMdysku można dostosować i w tym wpisie zobaczymy jak to zrobić.

Zmiana identyfikatora UUID systemu plików EXT4 i kontenera LUKS

Mikhail Morfikov — Sat, 30 Jan 2016 16:52:05 +0000

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 i (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.

Kopia struktury dysku twardego

Mikhail Morfikov — Fri, 18 Dec 2015 17:01:12 +0000

Wszyscy wiedzą, że zabawa z dyskiem zwykle kończy się tragicznie dla zawartych na nim danych. W tym wpisie spróbujemy się przyjrzeć sytuacjom, które nie jednego użytkownika linux'a potrafią przyprawić o zawał serca. Chodzi generalnie o uszkodzenie struktury dysku, oczywiście tylko tej programowej. Na błędy fizyczne nie możemy zbytnio nic poradzić. Natomiast jeśli chodzi o sferę logiczną, to mamy tutaj dość duże pole do popisu i jesteśmy w stanie się zabezpieczyć przed wieloma krytycznymi sytuacjami. Postaramy się tutaj omówić to jak wykonać kopię dysku. Taka kopia będzie miała tylko kilka (ew. kilkanaście) MiB, w skład której wchodzić będzie superblok systemu plików, nagłówki zaszyfrowanych partycji LUKS, struktura LVM i tablica partycji. Uszkodzenie każdego z tych powyższych uniemożliwia nam dostęp do danych zgromadzonych na dysku.

Zmiana rozmiaru partycji FAT32 pod linux'em

Mikhail Morfikov — Thu, 17 Dec 2015 16:05:23 +0000

Partycje mające system plików FAT32 są głównie wykorzystywane w przypadku pendrive i innych pamięci flash, gdzie nie mamy do czynienia ze sporą ilością danych czy też dużymi plikami. Czasem się zdarza tak, że układ partycji, który chcieliśmy zrobić, nie wyszedł nam tak jak powinien i musimy tego pendrive jeszcze raz przeformatować. Pół biedy, gdy na nim nie ma żadnych danych lub mamy możliwość zgrania ich na osobny dysk. Natomiast w przypadku, gdy nie możemy z jakiegoś powodu skorzystać z w/w opcji, to musimy liczyć się z utratą danych. Oczywiście, możemy także spróbować zmienić rozmiar takiej partycji i nic nie powinno się stać znajdującym się na niej danym. W tym wpisie postaramy się przejść przez proces zmiany rozmiaru partycji mającej system plików FAT32 i zobaczymy czy nasz linux poradzi sobie z tym zdaniem bez większego problemu.

Zmiana rozmiaru partycji EXT4

Mikhail Morfikov — Wed, 16 Dec 2015 19:06:57 +0000

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.

Zmiana rozmiaru partycji NTFS pod linux'em

Mikhail Morfikov — Wed, 16 Dec 2015 18:03:54 +0000

Zmiana rozmiaru partycji, nie tylko tej zawierającej system plików NTFS, nie sprawia w dzisiejszych czasach praktycznie żadnych problemów. Mamy przecie do dyspozycji takie narzędzia jak gparted, które w dużej mierze automatyzują cały proces tworzenia i usuwania partycji, czy też zmiany ich rozmiaru. W tym wpisie przyjrzymy się temu procesowi z bliska, z tym, że nie będziemy korzystać z żadnych graficznych nakładek. Wszystkie kroki postaramy się zreprodukować ręcznie z poziomu konsoli przy pomocy takich narzędzi jak fdisk czy ntfsresize .

Jak wymusić sprawdzenie systemu plików w systemd

Mikhail Morfikov — Fri, 04 Dec 2015 20:11:46 +0000

Jakiś czas temu opisywałem jak w systemach linux'owych przeprowadzić sprawdzenie systemu plików pod kątem ewentualnych błędów. Był tam poświęcony kawałek na temat ręcznego wymuszenia takiego skanowania. Ten sposób, który został opisany w tamtym wpisie działa wyśmienicie w przypadku sysvinit. Natomiast przy systemd mogą pojawić się pewne problemy, w efekcie czego nie będziemy w stanie wymusić skanowania pewnych partycji. Generalnie to rozchodzi się o tę główną, na której znajduje się system plików / . Postanowiłem się przyjrzeć nieco temu mechanizmowi i sprawdzić czy faktycznie nic nie da się zrobić i czy musimy czekać pełną ilość cykli startu systemu, by ten system plików został przez niego przeskanowany automatycznie.

Jak odzyskać usunięte z dysku pliki

Mikhail Morfikov — Mon, 30 Nov 2015 19:03:05 +0000

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 .

Całkowite usuwanie plików przy pomocy shred

Mikhail Morfikov — Tue, 24 Nov 2015 15:11:32 +0000

W przypadku, gdy musimy pozbyć się jakiegoś pliku, który znajduje się na dysku, to nie jest zalecane korzystanie z narzędzia rm . Usuwa ono jedynie odnośnik do pliku, który go identyfikuje w strukturze systemu plików, tzw. i-węzeł (i-node). To co uzyskujemy za pomocą takich narzędzi jak rm , to jedynie oznaczenie pewnych bloków (tych od pliku) jako wolne, w których system operacyjny będzie w stanie dokonać zapisu danych późniejszym czasie. Podczas tej operacji nie są usuwane żadne informacje z dysku, a mając na uwadze ten fakt, możemy bez problemu tak "usunięty" plik odzyskać. By mieć pewność, że plik zostanie trwale zniszczony, trzeba go ponownie napisać, np. przy pomocy shred, który standardowo jest dostępny w każdej dystrybucji linux'a i to jemu będzie poświęcony ten wpis.

Migracja systemu plików ext2 i ext3 na ext4

Mikhail Morfikov — Thu, 12 Nov 2015 14:16:49 +0000

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ć.

Montowanie katalogu /tmp/ jako tmpfs

Mikhail Morfikov — Wed, 21 Oct 2015 22:19:14 +0000

Linux jest w stanie operować na wielu systemach plików, np. ext4, ntfs, fat. Większość z nich odnosi się do dysków twardych, czy też innych urządzeń przechowujących spore ilości danych. Problem z tego typu systemami plików jest taki, że operacje na plikach w ich obrębie, jak i same pliki, zostawiają ślady. Dlatego też jeśli musimy tymczasowo skopiować plik zawierający tajne dane, lub też taki plik poddać obróbce, nie powinniśmy go umieszczać bezpośrednio na dysku. No chyba, że wykorzystujemy pełne szyfrowanie. Inną opcją (i o wiele prostszą w implementacji) jest przeznaczenie części pamięci operacyjnej RAM pod system plików tmpfs i o tym będzie ten wpis.

Kompaktowanie katalogów w systemie plików ext4

Mikhail Morfikov — Sat, 11 Jul 2015 13:39:06 +0000

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?