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.

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.

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

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.

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 .

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.

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

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.

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?