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 .

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

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?

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?

W poprzednim wpisie dostosowywaliśmy zarezerwowane miejsce na określonych partycjach dla systemowych procesów. Okazuje się także, że zmiana etykiety systemu plików może przysporzyć wiele problemów początkującym użytkownikom linuxa. Choć jeśli chodzi akurat o nadawanie czy zmianę etykiet, to tutaj już mamy możliwość przeprowadzenia tej operacji z poziomu narzędzi GUI, takich jak gparted , z tym, że niektóre jego komunikaty mogą nieco odstraszać.

Zwykle nie zwracamy uwagi na to jak formatujemy partycje w systemie linux i akceptujemy domyślne ustawienia jakie przyjęli sobie deweloperzy danej dystrybucji. Nie ma tutaj znaczenia czy instalujemy świeży system za pośrednictwem instalatora i przy jego pomocy kroimy dysk, czy też tworzymy partycje indywidualnie już z poziomu jakiegoś zainstalowanego systemu, bądź też płytki czy pendrive live. Domyślne ustawienia mają spełniać oczekiwania jak największej liczby odbiorców i nie zawsze nam one odpowiadają. W przypadku formatowania dysku, problematyczne może być rezerwowanie miejsca dla procesów użytkownika root.

Systemy plików stosuje się dla różnych nośników danych, takich jak dyski twarde, czy pendrive albo nawet płyty cd/dvd. Z formalnego punktu widzenia, system plików jest to metoda przechowywania danych i uzyskiwania do nich dostępu. Bez tego mechanizmu, informacje umieszczone na nośniku przypominały by jedynie ciąg bitów i nie wiedzielibyśmy gdzie zaczyna się jakiś plik i gdzie się on kończy. Czasami jednak zdarzają się błędy w systemie plików, które mogą doprowadzić do poważnych awarii systemu operacyjnego. Dlatego też linux co kilkanaście lub kilkadziesiąt uruchomień sprawdza stan systemu plików na każdej partycji i naprawia ewentualne błędy. W przypadku gdyby nie były one naprawiane, mogą pojawić się nowe błędy doprowadzając tym samym do całkowitej zapaści systemu.

Parę dni temu opisywałem jak udało mi się realokować uszkodzony sektor z dysku, który już przepracował dość długi okres czasu. Nie było to znowu jakoś specjalnie trudne, z tym, że cały problem dotyczył jakiegoś losowego sektora gdzieś w środku partycji. Jako, że domyślnym systemem plików na linuxie są te z rodziny ext (ext2, ext3, ext4) , oraz, że trzecia wersja tego systemu plików została wyposażona w dziennik (journal), to trzeba by się zastanowić, co w przypadku gdy taki uszkodzony sektor trafi się właśnie w dzienniku tego systemu plików?