Forum Debian Users Gang

Do pewniejszego zerowania dysku możesz użyć shred.

No bo zakładałem, że chodziło o coś więcej ;)

yossarian -- jaki cel w tym jest? xD Przecie nadpisywanie całych bloków ma sens tylko w przypadku usuwania konkretnych plików, no bo usuwane są tylko inode ale plik fizycznie dalej istnieje tylko nie ma do niego odwołania z ludzkiego punktu widzenia. Poza tym, jak wgrywamy jakiś nowy plik w miejsce starego to może się zdarzyć tak, że po tym starym zostaną dziury, np. wgramy 5 plików o "takim samym rozmiarze" co miał ten duży usunięty, to w paru miejscach mogą zostać niezapisane pełne bloki i z tych dziur można odzyskać kawałki informacji, choć przy dużych plikach odzyskanie paru KiB danych na pewno pomoże w czymś xD

Nie widzę też sensu nadpisywania 20x tego samego miejsca na dysku w celu "pewniejszego" zerowania dysku, a w przypadku czyszczenia całej powierzchni dysku /dev/zero w zupełności wystarczy, choć ja tam zawsze bym stworzył kontener tak jak opisano na archwiki i wypełnił dysk zaszyfrowanymi zerami, po czym nadpisał zerami nagłówki partycji i tyle.

Nigdy was nie zastanawiały te dwie wartości?

total size: 15.2 K  ( 15539 bytes )
size on disk: 16.0 K  ( 16384 bytes )

Albo inny przykład: stworzyłem sobie nowy pliczek textowy i wpisałem tam jeden znak, poniżej staty pliku:

total size: 2 B  ( 2 bytes )
size on disk: 4.0 K  ( 4096 bytes )

Jako, że system plików na tej partycji używa bloku o rozmiarze 4096 bajtów to w "size on disk" zawsze będzie wielokrotność 4K, ale jak widać w pierwszym przypadku jest dziura 845B a w drugim 4094B i jeśli tam był jakiś plik wcześniej, można podejrzeć co się tam znajdowało. Shred po prostu nadpisze w pełni wszystkie bloki, na których znajduje się dany plik Czyli całe 16K albo 4K i jeśli plik nie jest pofragmentowany to jego rozmiar na dysku zawsze będzie większy o 4KiB. To samo można osiągnąć przez dd i ręczne wyliczenie ile bloków ma zostać nadpisanych przy kasowaniu pliku a potem usunąć tylko inode. Shred to robi automatycznie, ale według mnie nadpisywanie xx razy tego samego pliku przy pomocy shreda jest po prostu głupie. xD

A co do problemów z dyskiem.

drelbrown -- a jakież to błędy logiczne masz?

Eee, nie? Ale skoro zadajesz pytanie, to chyba musi być jakaś przyczyna.

A błędy logiczne nie są błędami w wyniku sypnięcia się systemu plików?

Jeśli chcesz się przed nimi zabezpieczyć, to musisz aktywować skanowanie dysku po 20 restartach (itd.)
Niestety, ktoś pił wodę z muszli i wyłączył automatyczne skanowanie systemu plików

Fervi

I w jaki sposób zerowanie miałoby pomoc w przywróceniu danych? xD Tu raczej trzeba zrobić kopie superbloków, choć w sumie kopie są, wystarczy sobie pospisywać numery zapasowych bloków i na wypadek problemów z systemem plików, puszczać fsck z alternatywnych lokalizacji, to zawsze pomaga naprawić system plików. Co do samego sprawdzania co każdy mount, jeśli traktujesz kompa nieprzyzwoicie to pewnie się to nada albo gdy uptime idzie w miesiące, ale to nie ma większego sensu jeśli zasilanie jest stabilne a kompa wyłączasz parę razy dziennie. Poza tym, zawsze jak ci zdechnie pc, to zwykle z automatu jest puszczany fsck, a jeśli masz jakieś podejrzenia, że coś nie gra, tak jak ja miałem ostatnio, to możesz wymusić sprawdzanie wszystkich wpisów w /etc/fstab przy pomocy parametru -F dodanego do shutdown. Ja operuję na zaszyfrowanych voluminach od ponad 5 lat i jeszcze nie straciłem ani jednego bita danych, no może pomijając te 4GiB przy badbloku ale tak to wszystko działa jak należy, także wiem co gadam i naprawdę, trzeba się bardzo nieprzyzwoicie obchodzić z pc, żeby ten tak sam z siebie zaczął niszczyć wszelkie dane na nim zawarte. xD

drelbrown napisał(-a):

Chodzi mi o zerowanie w celu naprawy błędów logicznych HDD, itp.

no to badblocks. możesz sobie ustawić dowolny pattern jaki chcesz. jeśli preferujesz zera, to po prostu podajesz odpowiednią opcję -t

morfik napisał(-a):

ja wyraźnie poprosiłem o wyjaśnienie sformułowania "błędy logiczne dysku twardego"

w przypadku błędów logicznych, to w "normalnej" rozmowie z "normalnymi" ludźmi należy się spodziewać błędów systemu plików, na które zwykły tzw. "format" poradzi (czyli zakładamy na urządzeniu nowy system plików i błędy znikają).

i tu pojawia się sakramentalne ALE: - ale obecnie rozjeżdża się granica miedzy "logicznymi" a "sprzętowymi" sektorami, bo np. taki SMART zapamiętuje ujebane sprzętowe (prawdziwe sprzętowe!) sektory i zapisuje ich adres w swoim flashu. no, i teraz pojawia się zagadka filozoficzna: czy adresy uszkodzonych sektorów w pamięci jakiegoś obsranego kontrolera SMART to są jeszcze błędy sprzętowe, czy już logiczne.

jak dla mnie drelbrown ma błędy sprzętowe, tylko źle zaczął temat. zamiast np.: "chłopaki, syslog wywala mi takie dziwactwa: [tutaj lista kopiuj-wklej z logów], kernel wali jakieś dziwne komunikaty, nie wiem o co kaman, ale wklejam [tu lista kopiuj-wklej]" i tym podobne, to zaczął zupełnie od dupy strony.

drelbrown, ludzie na dugu to nie są wredni chuje, tylko kumate i nawet takie sprytne cwaniury. nawet chętnie ci pomogą, bo uważają to za pewien rodzaj sportu. no i im tez kiedyś ktoś pomógł i prowadził ich za rączkę, więc pomagając innym płacą stare długi. musisz jedynie postarać się opisać swój problem w jasny i możliwie jak najmniej skomplikowany sposób, bo nie mamy tu szklanych kul i czarnych kotów, rozumiesz.

drelbrown napisał(-a):

Ja mam ustawione tune2fs -c 1 dla każdej partycji. Kiedyś mi się sypnął ext4, a odzysk danych z niego to była masakara.

To co się posypało?
Zazwyczaj wystarczy z LiveCD odpalić Linuksa i fsck /dev/sd*
Przeskanuje, wywali co mu się nie podoba, naprawi i szafa gra

Ciekawi mnie czy przez takie wysypanie się można stracić dane ...

Fervi