Morfitronik Security & Privacy

Badsector dysku HDD w kontenerze LUKS zawierającym LVM

2019-03-31 13:23:42
Morfik

Podczas rutynowego skanu powierzchni dysków HDD w moim laptopie, S.M.A.R.T wykrył w jednym z nich podejrzany blok, który zdawał się wyzionąć już ducha, przez co proces weryfikacji integralności powierzchni dysku twardego nie był w stanie zakończyć się z powodzeniem. Komunikat zwracany przy czytaniu padniętego sektora też był nieco dziwny: bad/missing sense data, sb[] . Jakiś czas temu już opisywałem jak realokować uszkodzony sektor dysku HDD i w zasadzie wszystkie informacje zawarte w tamtym artykule można by wykorzystać do próby poprawienia zaistniałego problemu, gdyby tylko nie fakt, że w tym przypadku badblock znalazł się w obszarze voluminu logicznego LVM na partycji zaszyfrowanej przy pomocy mechanizmu LUKS. Taki schemat układu partycji sprawia, że do realokowania błędnego bloku trzeba podejść nieco inaczej uwzględniając w tym procesie kilka offset’ów, bez których w zasadzie nic nie da się zrobić. Postanowiłem zatem napisać na konkretnym przykładzie jak realokować badsector dysku, gdy do czynienia mamy z zaszyfrowanym linux’em zainstalowanym na voluminach LVM.

Błędy dysku

Wszystko zaczęło się od niewinnego skanu S.M.A.R.T, bo do chwili jego wykonania w zasadzie mój Debian jak i dysk, na którym ten system jest zainstalowany, działał bez zarzutu. W logu systemowym nie było żadnych komunikatów świadczących o jakiekolwiek awarii nośnika, czy ewentualnych problemach z odczytem jego powierzchni. Niemniej jednak, w raporcie S.M.A.R.T widniał taki oto błąd:

Error 4 [3] occurred at disk power-on lifetime: 22336 hours (930 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 51 00 01 00 00 00 5e a7 db e0 00  Error: UNC at LBA = 0x005ea7db = 6203355

  Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  20 00 00 00 01 00 00 00 5e a7 db e0 00     01:47:04.105  READ SECTOR(S)
  ec 00 00 00 01 00 00 00 00 00 00 40 00     01:47:04.103  IDENTIFY DEVICE
  ef 00 10 00 03 00 00 00 00 00 00 a0 00     01:47:01.930  SET FEATURES [Enable SATA feature]
  ef 00 10 00 02 00 00 00 00 00 00 a0 00     01:47:01.920  SET FEATURES [Enable SATA feature]
  ec 00 00 00 00 00 00 00 00 00 00 a0 00     01:47:01.918  IDENTIFY DEVICE

No i widać tutaj Error: UNC at LBA oraz numer bloku, do którego ten błąd się odnośni: 6203355 .

Właściwie to tych błędów było kilka, co musiało oczywiście przerwać proces skanowania:

Patrząc w podsumowanie raportu parametrów dysków, można zauważyć, że ten sektor został przeznaczony do realokacji:

ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
...
  5 Reallocated_Sector_Ct   PO--CK   200   200   140    -    0
...
196 Reallocated_Event_Count -O--CK   200   200   000    -    0
197 Current_Pending_Sector  -O--CK   200   200   000    -    1
198 Offline_Uncorrectable   ----CK   100   253   000    -    0

Wygląda na to, że są jakieś większe problemy z odczytaniem tego bloku numer 6203355 . Spróbujmy zatem odczytać go ręcznie:

# time hdparm --read-sector 6203355 /dev/sda
/dev/sda:
reading sector 6203355: SG_IO: bad/missing sense data, sb[]:  70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 00 db 00 00 00 00 00 00 00 00 00 00 00 00 00 00
succeeded
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0.00s user 0.01s system 0% cpu 2.174 total

To dopiero ciekawa przypadłość, bo niby hdparm udało się odczytać ten sektor ( succeeded ) ale błąd bad/missing sense data, sb[]: nie brzmi jakość szczególnie miło. Jeśli zwrócimy uwagę na czas w jakim ten sektor został odczytany, to widać, że ta czynność zajęła ponad 2 sekundy. W przypadku czytania zdrowego sektora otrzymuje się coś na poniższy wzór:

# time hdparm --read-sector 6203356 /dev/sda
/dev/sda:
reading sector 6203356: succeeded
...
0.00s user 0.00s system 22% cpu 0.021 total

Nie ma zatem ani widocznego wyżej błędu, a sam odczyt to kwestia kilku milisekund.

Warto tutaj zaznaczyć, że podczas czytania tego badsector’a przy pomocy hdparm , w logu systemowym nie pojawiły się jakiekolwiek błędy. To trochę dziwna sytuacja, bo zwykle w takich przypadkach system powinien zacząć narzekać, że coś uniemożliwia poprawne czytanie powierzchni dysku.

Czym jest bad/missing sense data

Z początku nie miałem pojęcia jak zinterpretować ten błąd bad/missing sense data i te wartości HEX, które zostały zwrócone. Ten cały komunikat można jednak zdekodować przy pomocy narzędzia sg_decode_sense zawartego w Debianie w pakiecie sg3-utils :

$ sg_decode_sense 70 00 03 00 00 00 00 0a 40 51 e0 01 11 04 00 00 00 db 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Fixed format, current; Sense key: Medium Error
Additional sense: Unrecovered read error - auto reallocate failed

Wygląda na to, że mamy do czynienia z uszkodzonym blokiem dysku, który wymaga ręcznej realokacji.

Ustalenie partycji z badblock’iem

Gdy przytrafi nam się ten cały bad/missing sense data , to nie ma innego wyjścia jak realokować blok danych, który powoduje błąd odczytu. Całą zabawę zaczynamy standardowo od ustalenia przy pomocy fdisk/gdisk (czy innych narzędzi do partycjonowania dysku), na której partycji ten padnięty sektor się znajduje:

# fdisk -l /dev/sda
Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Disk model: WDC WD2500BEKT-6
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0006320c

Device     Boot   Start       End   Sectors   Size Id Type
/dev/sda1  *       2048   4196351   4194304     2G 83 Linux
/dev/sda2       4196352 488396799 484200448 230.9G 83 Linux

Jako, że numer problematycznego bloku wskazuje na 6203355 , to wiadomo, że znajduje się on na partycji sda2 , bo 6203355 zawiera się w przedziale między 4196352 a 488396799 . W tym przypadku jest to zaszyfrowany kontener LUKS z kilkoma voluminami logicznymi LVM w środku.

Offset badblock’u

Mając informacje o początku partycji musimy znaleźć offset badblock’u względem tej partycji. Odejmujemy zatem od numeru LBA (widocznego w logu S.M.A.R.T) wartość w kolumnie start (widoczną wyżej w wyjściu fdisk ) dla partycji sda2 : 6203355 − 4196352 = 2007003 .

Rozmiar fizycznego zakresu bloków LVM

Musimy teraz znaleźć volumin logiczny LVM, do którego ten uszkodzony blok należy. Ustalamy na początek rozmiar fizycznego zakresu bloków LVM (Physical Extent, PE):

# pvdisplay -c /dev/mapper/sda2_crypt | awk -F: '{print $8}'
4096

Rozmiar fizycznego zakresu to 4096 KiB, czyli 4 MiB (standardowy kawałek).

Ten dysk ma 512 bajtowe sektory, czyli 0,5 KiB. Musimy to uwzględnić w wyliczeniach i pomnożyć otrzymaną wyżej wartość przez 2, co daje nam 4096 * 2 = 8192 bloków na każdy fizyczny zakres LVM (8192 * 512 = 4194304, czyli również 4 MiB).

Dyski logiczne nie zaczynają się zaraz na początku partycji fizycznej dysku HDD. W tym przypadku na początku partycji znajduje się nagłówek LUKS, a po nim nagłówek LVM. Te dwa offsety musimy znać.

Offset kontenera LUKS

Kontener LUKS zwykle zaczyna się na początku partycji ale zaszyfrowane dane zawarte w nim znajdują się zaraz za nagłówkiem LUKS. Informacje o przesunięciu tych danych możemy wyciągnąć przez cryptsetup :

# cryptsetup luksDump /dev/sda2
LUKS header information
Version:        2
Epoch:          7
Metadata area:  16384 [bytes]
Keyslots area:  2064384 [bytes]
UUID:           e017ac1c-c46f-4b3f-a319-e1f5ed15144a
Label:          wd_black_label
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
  0: crypt
        offset: 2097152 [bytes]
        length: (whole device)
        cipher: aes-xts-plain64
        sector: 512 [bytes]

Keyslots:
  0: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        PBKDF:      argon2i
        Time cost:  2
        Memory:     1048576
        Threads:    1
        Salt:       7e d0 31 80 49 c9 ba 1d 86 42 dd 76 69 4e 2a 99
                    b6 79 82 64 76 0c a0 ad ea 4b 3f 97 66 df 94 3c
        AF stripes: 4000
        AF hash:    sha256
        Area offset:32768 [bytes]
        Area length:258048 [bytes]
        Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
        Hash:       sha512
        Iterations: 56888
        Salt:       55 6e 7e aa 70 ce 81 e9 23 94 8c 07 35 32 09 9d
                    4a 06 cb 49 85 b3 4b 4c ec f1 44 18 86 da a8 da
        Digest:     fe b5 16 eb b3 20 73 9d a7 e2
                    e9 c8 c4 07 f6 ad 09 06 30 df

Mamy tutaj sekcję Data segments: i w niej offset: 2097152 [bytes] . Jest to 4096 sektorów 512 bajtowych, lub 2 MiB.

Offset LVM

Zakresy voluminów logicznych również nie zaczynają się na początku partycji fizycznej lub (tak jak w tym przypadku) zaraz za nagłówkiem LUKS. Bezpośrednio za nagłówkiem LUKS znajdują się metadane LVM. Musimy ustalić, gdzie zaczyna się wobec tego pierwszy fizyczny zakres bloków LVM. To zadanie można zrealizować na kilka sposobów. Najprościej jest odczytać offset z wyjścia polecenia pvs :

# pvs -o+pe_start /dev/mapper/sda2_crypt
  PV                     VG             Fmt  Attr PSize    PFree 1st PE
  /dev/mapper/sda2_crypt wd_black_label lvm2 a--  <230.88g 4.00g   1.00m

W ostatniej kolumnie mamy 1.00m , czyli nasz offset LVM to 1 MiB, co daje 2048 sektorów 512 bajtowych. Możemy to łatwo potwierdzić dodając do powyższego polecenia --units s :

# pvs -o pe_start --units s /dev/mapper/sda2_crypt
  1st PE
    2048S

Drugim sposobem na ustalenie offsetu fizycznych zakresów LVM jest przejrzenie plików backupu zlokalizowanych w /etc/lvm/backup/ :

# grep pe_start $(grep -l /dev/mapper/sda2_crypt /etc/lvm/backup/*)
                        pe_start = 2048

Ustalenie voluminu LVM zawierającego badblock

Mając wartość rozmiaru zakresu fizycznych bloków LVM, która wynosi 8192 , możemy ustalić volumin logiczny zawierający badblock. W tym celu trzeba podzielić offset padniętego bloku uzyskany w fdisk przez rozmiar zakresu: 2007003 / 8192 = 244.99548 . Sprawdźmy zatem jak prezentuje się mapa zakresów dysków LVM:

# lvdisplay --maps wd_black_label | egrep 'Physical|LV Name|Type'
  LV Name                freespace
	Type                linear
	Physical volume     /dev/mapper/sda2_crypt
	Physical extents    0 to 15
  LV Name                root
	Type                linear
	Physical volume     /dev/mapper/sda2_crypt
	Physical extents    16 to 10255
  LV Name                home
	Type                linear
	Physical volume     /dev/mapper/sda2_crypt
	Physical extents    11280 to 27663
  LV Name                kabi
	Type                linear
	Physical volume     /dev/mapper/sda2_crypt
	Physical extents    27664 to 59104

Liczba, którą wyżej otrzymaliśmy ( 244.99548 ) znajduje się w zakresie od 16 do 10255 . Zatem uszkodzony sektor jest gdzieś w obrębie partycji root .

Offset badblock’u w systemie plików ext4

Trzeba jeszcze odszukać ten badblock w systemie plików (w tym przypadku ext4) i ustalić co za plik w tym miejscu rezyduje. Do tego celu potrzebny nam będzie rozmiar bloku systemu plików:

# dumpe2fs /dev/mapper/wd_black_label-root | grep 'Block size'
dumpe2fs 1.45.0 (6-Mar-2019)
Block size:               4096

Widoczna wyżej wartość 4096 (4 KiB) to standardowy rozmiar bloku w systemie plików ext4.

Logiczny volumin LVM, który zawiera badsector, zaczyna się na fizycznym zakresie 16 . Mnożymy tę wartość przez rozmiar zakresu fizycznego i dodajemy do niego offset samego zakresu LVM jak i offset kontenera LUKS:

(ilość bloków LVM * rozmiar bloku LVM) + offset fizycznych zakresów + offset LUKS
(16 * 8192) + 2048 + 4096 = 137216

Mamy 512 bajtowe bloki na dysku, zatem uszkodzony blok ma w systemie plików ext4 na partycji root numer:

(offset bloku w fdisk - offset LUKS+LVM+volumin) / (rozmiar bloku ext4 / rozmiar sektora dysku)
(2007003 - 137216) / (4096 / 512) = 233723.38

Jeśli wszystko wyliczyliśmy prawidłowo, to przy próbie czytania bloku 233723 powinniśmy odnotować jakieś błędy w logu systemowym lub terminalu . Spróbujmy zatem odczytać ten blok przy pomocy dd :

# dd if=/dev/mapper/wd_black_label-root of=block233723 bs=4096 count=1 skip=233723
dd: error reading '/dev/mapper/wd_black_label-root': Input/output error
0+0 records in
0+0 records out
0 bytes copied, 3.90926 s, 0.0 kB/s

No i tutaj już mamy wyraźny błąd Input/output error . Natomiast w logu systemowym nieco więcej komunikatów:

kernel: ata1.00: exception Emask 0x0 SAct 0x10 SErr 0x40000 action 0x0
kernel: ata1.00: irq_stat 0x40000008
kernel: ata1: SError: { CommWake }
kernel: ata1.00: failed command: READ FPDMA QUEUED
kernel: ata1.00: cmd 60/08:20:d8:a7:5e/00:00:00:00:00/40 tag 4 ncq dma 4096 in
                                             res 41/40:00:db:a7:5e/00:00:00:00:00/40 Emask 0x409 (media error) <F>
kernel: ata1.00: status: { DRDY ERR }
kernel: ata1.00: error: { UNC }
kernel: ata1.00: configured for UDMA/100
kernel: sd 0:0:0:0: [sda] tag#4 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: sd 0:0:0:0: [sda] tag#4 Sense Key : Medium Error [current]
kernel: sd 0:0:0:0: [sda] tag#4 Add. Sense: Unrecovered read error - auto reallocate failed
kernel: sd 0:0:0:0: [sda] tag#4 CDB: Read(10) 28 00 00 5e a7 d8 00 00 08 00
kernel: print_req_error: I/O error, dev sda, sector 6203355 flags 80700
kernel: ata1: EH complete
kernel: ata1.00: exception Emask 0x0 SAct 0x2000 SErr 0x0 action 0x0
kernel: ata1.00: irq_stat 0x40000008
kernel: ata1.00: failed command: READ FPDMA QUEUED
kernel: ata1.00: cmd 60/08:68:d8:a7:5e/00:00:00:00:00/40 tag 13 ncq dma 4096 in
                                             res 41/40:00:db:a7:5e/00:00:00:00:00/40 Emask 0x409 (media error) <F>
kernel: ata1.00: status: { DRDY ERR }
kernel: ata1.00: error: { UNC }
kernel: ata1.00: configured for UDMA/100
kernel: sd 0:0:0:0: [sda] tag#13 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: sd 0:0:0:0: [sda] tag#13 Sense Key : Medium Error [current]
kernel: sd 0:0:0:0: [sda] tag#13 Add. Sense: Unrecovered read error - auto reallocate failed
kernel: sd 0:0:0:0: [sda] tag#13 CDB: Read(10) 28 00 00 5e a7 d8 00 00 08 00
kernel: print_req_error: I/O error, dev sda, sector 6203355 flags 0
kernel: Buffer I/O error on dev dm-2, logical block 233723, async page read
kernel: ata1: EH complete
smartd[1636]: Device: /dev/disk/by-id/ata-WDC_WD2500BEKT-60A25T1_WD-WX41A90E5928 [SAT], 1 Currently unreadable (pending) sectors
smartd[1636]: Device: /dev/disk/by-id/ata-WDC_WD2500BEKT-60A25T1_WD-WX41A90E5928 [SAT], SMART Usage Attribute: 187 Reported_Uncorrect changed from 93 to 91
smartd[1636]: Device: /dev/disk/by-id/ata-WDC_WD2500BEKT-60A25T1_WD-WX41A90E5928 [SAT], ATA error count increased from 7 to 9

Mamy tam informację Unrecovered read error - auto reallocate failed (tę samą, którą zdekodował nam sg_decode_sense ) . Czyli prawdopodobnie na tym bloku rezyduje jakiś plik, bo automatyczna realokacja się nie powiodła. Przynajmniej wiemy, że wszystkie wyliczenia wyżej zostały przeprowadzone prawidłowo. Jeśli ten sektor by się dał odczytać bez problemu, to prawdopodobnie coś źle policzyliśmy.

Realokowanie błędnego bloku

By realokować ten uszkodzony sektor musimy go zapisać. Warto zatem ustalić, który plik trzeba będzie skasować, bo nie będzie się on już nadawał do odzyskania. Odpalamy zatem debugfs i wskazujemy w nim ten blok, który próbowaliśmy odczytać w dd :

# debugfs
debugfs 1.45.0 (6-Mar-2019)
debugfs:  open /dev/mapper/wd_black_label-root
debugfs:  testb 233723
Block 233723 not in use

To ciekawe, niby automatyczna realokacja badblock’u się nie powiodła ale ten blok nie jest wykorzystany przez żaden plik. Do tej pory myślałem, że blok może zostać automatycznie realokowany jedynie w sytuacji, w której żaden i-node (i-węzeł) się do niego nie odwołuje. Wygląda jednak na to, że puste bloki też mogą mieć problemy z automatyczną realokacją.

Spróbujmy zapisać ten blok przy pomocy dd :

# dd if=/dev/zero of=/dev/mapper/wd_black_label-root count=1 bs=4096 seek=233723
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000132102 s, 31.0 MB/s

Jak widać, zapis bloku dokonał się bez większego problemu. Może jednak zapisaliśmy nie ten blok, który powinniśmy? Spróbujmy ponowić odczyt bloku, który wcześniej wyrzucił nam sporo błędów (chodzi o użycie tego samego polecenia co wcześniej):

# dd if=/dev/mapper/wd_black_label-root of=block233723 bs=4096 count=1 skip=233723
1+0 records in
1+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.00075293 s, 5.4 MB/s

No i proszę, uszkodzony sektor się odblokował. A jak prezentuje się wyjście hdparm ?

# time hdparm --read-sector 6203355 /dev/sda

/dev/sda:
reading sector 6203355: succeeded
6cf9 cd2a 7d6e 84c9 6685 bc59 62a5 2192
abd0 ca00 c518 c183 578b 66b6 8115 5b89
75c8 5381 7178 1702 358f 605d ebc6 6075
4f66 b633 7d84 07e4 1ca6 33f1 d1fb 126f
86b6 9642 244b f5b2 2709 4060 5954 8635
bd50 fa22 3a0e 2023 8459 e791 822b 416f
bfb9 0912 1ea2 7c34 9ba9 732c 3e7b ddfb
0c5e f190 2a25 991a 5f24 a402 0cfe 1d9f
a458 6815 45a4 ac90 9246 b081 8ee2 ba72
1383 7f9c 5824 3532 0095 bea0 271f b67b
1a0c a281 a7bf b4aa 7b58 0533 81e0 b219
73f3 b228 77b2 1bc7 ec61 dce2 df62 2b49
addf 216a fd10 a38c e090 1304 ef44 6afc
abc4 2d05 e36b 2f29 080b a5df 6735 bb2f
28d5 1fde 40d3 0010 45f1 a21d a311 6409
75f3 7f76 eecd 5c71 2687 b0fd 925e 8aa5
7e7e 9e99 29e2 1ecd 5cff badc 78c2 8e83
b610 179d 770c 58f8 a012 547c b6b9 5ef3
8145 ef62 36cb 5900 4c24 48a6 0c62 98fe
5381 3775 83ff 3483 6b27 a856 e875 68c5
8832 f0ca 576a add5 fc9b 9813 9db7 907b
646e 715c 2b9e 5098 c83e 65c2 d1db d734
f988 3fae dfec b465 fbcc 7235 cafa f4c5
211d 34f8 e356 11a9 cf0e 03ec ea05 a47f
7fc6 a98f 6a7c 0a15 7122 cc9c 152f 2840
2317 a76a 3dad 8888 8d47 edb2 541e 500a
ec0d e2e8 8ba9 cd71 270f bc9b aec6 ae78
e219 d719 009b 176f 960b f052 9063 9658
8e6b 739a e9c3 fd5f b51a 043e 902c 3e3b
2cc3 92ac fb4d 0e7f 81d8 c49b 51d1 41f9
ef4e c4b4 d9ca 84f2 b70b c391 1d3b 7e34
c442 c3d2 2078 1cc1 0ac3 260a b900 41f8
0.00s user 0.01s system 59% cpu 0.009 total

Czas dostępu jest niski, no i nie ma również samych 0000 , tak jak to było wcześniej.

Pełny skan S.M.A.R.T

Wypadałoby teraz przeskanować całą powierzchnię dysku i rzucić okiem na raport S.M.A.R.T. W tym przypadku skanowanie zakończyło się już powodzeniem:

A raport pokazuje, że sektor udało się uratować:

ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
...
  5 Reallocated_Sector_Ct   PO--CK   200   200   140    -    0
...
196 Reallocated_Event_Count -O--CK   200   200   000    -    0
197 Current_Pending_Sector  -O--CK   200   200   000    -    0
198 Offline_Uncorrectable   ----CK   100   253   000    -    0

Więcej informacji na temat próby odzyskania uszkodzonych sektorów można znaleźć tutaj.


Komentarze

Zawartość wpisu