Generalnie dysk to jeden wielki
blok bajtów. Jak bardzo chcesz, to możesz zrobić program, który (z prawami roota) otworzy
fopen() bezpośrednio np.
/dev/sdb i będzie używał sobie całego dysku jak wielkiego pliku:
..............................................................................................Tyle, że nie jest to zbyt praktyczne. Stąd też partycje i systemy plików.
Aby były
partycje, musisz mieć tablicę partycji MBR (albo GPT) [1-4].
Tablica partycji dzieli powierzchnię dysku znów na kilka mniejszych ciągłych podbloków. Mówi gdzie partycja się zaczyna i gdzie kończy. I tylko tyle.
(Są jeszcze dyski logiczne, które wyglądają odrobinę inaczej, ale dla użytkownika i tak jest to praktycznie przeźroczyste.)
MBR zawiera też informacje o programie rozruchowym systemu operacyjnego, i to właśnie w MBR dysku BIOS szuka tych danych gdy uruchamia komputer "z danego dysku".
Więc
/dev/sdb1,
/dev/sdb2, ... to znów po prostu bloki bajtów odpowiadające pewnemu zakresowi powierzchni dysku.
Znów możesz je sobie otworzyć jak zwykły plik i po nich pisać:
MBR[..........................................................][.................][..........]Ale to nadal nie jest wygodne, mamy więc
systemy plików.
Dopiero teraz pojawia się
formatowanie.
Formatując partycję powodujesz, że ten wielki blok bajtów będzie posiadał strukturę (narzuconą przez dany system plików) i będzie zarządzany przez system operacyjny.
Co wchodzi w skład systemu plików na takiej partycji? Przede wszystkim dwie zupełnie rozdzielne rzeczy: sektory zawierające metadane plików i katalogów, oraz sektory zawierające pocięte dane z samych plików (im bardziej pocięte, tym większa fragmentacja dysku).
MBR[{X..........}{...........................................}][.................][..........]MBR[{XABC.......}{aaaaaaabbbcccbbb...........................}][.................][..........](Tak na prawdę jest kilka kopii tablicy alokacji rozrzuconych po całej partycji. Polecenia
mkfs.* informuje o ich lokalizacjach podczas formatowania.)
Natomiast usuwając plik tak na prawdę
niczego nie usuwasz. Oznaczasz tylko, że sektory zawierające dane pliku nie są już używane i mogą być (w przyszłości) nadpisane nowym plikiem - ale na razie ich zawartość zostaje, bo po co marnować czas na ich czyszczenie. Z nazwą pliku jest różnie w różnych systemach plików, ale także może zostać tylko oznaczona jako już nieistniejąca, ale sam ciąg znaków nadal nie zniknie z powierzchni dysku. W systemach
ext jeden rekord (inode) wskazuje na inny, tworząc drzewo [5]. "Usunięcie" wpisu polega na odpięciu takiego inode od drzewa, ale niekoniecznie fizycznym usunięciu jego metadanych z dysku:
MBR[{XABC.......}{aaaaaaabbbcccbbb...........................}][.................][..........]Stąd też np. polecenie
wipe, poza nadpisaniem zawartości pliku, domyślnie zmienia także jego nazwę przed usunięciem - aby to co zostanie w tablicy alokacji było losowym ciągiem znaków:
MBR[{XABW.......}{aaaaaaabbbwwwbbb...........................}][.................][..........]Natomiast formatowanie nie powoduje usunięcia
żadnych danych - ani zawartości plików, ani tego drzewa metadanych. Tworzy tylko nowy korzeń drzewa (i katalog lost+found). Reszta tego drzewa pozostaje odcięta i nadal widnieje zapisana fizycznie na dysku. Dlaczego? Bo system nie będzie bawił się w odczytywanie starego systemu plików (który może być dowolny, nieobsługiwany, może go nie być, albo mogą być w tym miejscu losowe dane) aby odnaleźć jaką część dysku stanowiła poprzednia tablica alokacji i ją usunąć:
MBR[{YABC.......}{aaaaaaabbbcccbbb...........................}][.................][..........]Więc:
po usunięciu danych z partycji i nadpisaniu ( np. zerofree ) jej powierzchni - gdy wykonam format - to zostanie usunięta tablica alokacji plików
nie jest prawdą. Danych (najprawdopodobniej) nie będzie, ale tablica alokacji pozostanie na dysku do odczytania.
Jak zobaczyć co jest na dysku? Odmontować partycję (np.
/dev/sdb1) i obejrzeć ją edytorem heksadecymalnym jak zwykły plik.
Tyle, że to będzie duuuuży plik. Więc jeśli chcesz się tylko przekonać na własne oczy co jest na dysku to proponuję poniższe:
To, że te partycje to wielkie bloki bajtów działa też w drugą stronę. Możesz stworzyć sobie jakiś plik (np. 50MB), a następnie go sformatować aby zawierał w sobie jakiś system plików i taki plik zamontować jak dysk:
$ dd if=/dev/zero of=plik.dat bs=1M count=50
$ /sbin/mkfs.ext4 plik.dat
$ mkdir montownia
$ sudo mount -t ext4 plik.dat montowniaPolecenie
mount pokaże zamontowany system plików.
$ sudo mkdir montownia/dane
$ sudo chown 1000:1000 montownia/dane
$ cd montownia/dane
$ echo "tajne dane" > tajny_plik.txt
$ rm tajny_plik.txt
$ cd ../..
$ sudo umount montowniaI po odmontowaniu możesz obejrzeć
plik.dat edytorem heksadecymalnym i poszukać charakterystycznych ciągów znaków: "tajne dane" oraz "tajny_plik.txt". Będą tam wszystkie.
A propos tego pliku z partycją - można tak też zrobić sobie szyfrowaną partycję w postaci zwykłego pliku do zamontowania. Wtedy wszelkie pozostawione dane łącznie z tablicą alokacji plików i tak są zaszyfrowane, a więc nie odczyta się ich edytorem heksadecymalnym (chyba, że zna się hasło do partycji).
A jak poprawnie wyczyścić partycję?
Najpierw odmontować. Potem:
dd if=/dev/zero of=/dev/sdb1 bs=1MI dopiero teraz formatujemy ją na nowy system plików.
Po jednokrotnym nadpisaniu dane są nie do odczytania za pomocą zwykłego komputera. Choć w laboratorium nadal da się je odzyskać, szczególnie gdy nadpisujesz zerami. Szacuje się, że trzeba nadpisywać 25-35 razy, aby było to fizycznie skuteczne. Bezpieczniejsze jest też użycie losowych danych, ale jest to dłuższe (generowanie losowych danych obciąża CPU):
dd if=/dev/urandom of=/dev/sdb1 bs=1MI należy wtedy pamiętać, aby, zanim utworzymy nowy MBR i partycje, oczyścić zerami początek dysku (minimum 4k), bo losowe dane w tej części mogą nie spodobać się BIOSowi:
dd if=/dev/zero of=/dev/sdb1 bs=4k count=1[1]
https://pl.wikipedia.org/wiki/Master_Boot_Record[2]
https://pl.wikipedia.org/wiki/GUID_Partition_Table[3]
https://en.wikipedia.org/wiki/Master_boot_record[4]
https://en.wikipedia.org/wiki/GUID_Partition_Table[5]
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Hash_Tree_Directories