Portál AbcLinuxu, 5. května 2025 18:46
ddrescue
a toho druhého programu, co je úplně jiný, ale jmenuje se skoro stejně. Nicméně se domnívám, že je to boj, který nelze vyhrát.
Postup, kdy u nového nebo nově zakoupeného postaršího disku nejprve uděláš dd
do /dev/null
nebo ekvivalent, je velmi dobrý. Při čtení si totiž disk nemůže vymýšlet. Buď (s větším či menším úsilím) data z disku dokáže vydolovat, nebo ne. (Větší úsilí by mělo teoreticky vyvolat nějaké chyby, které by se objevily v dmesg
, ale některé disky je tiše zatlučou.)
Při zápisu je situace jiná. Disk zapíše sektor a obratem kontroluje, zda se zdařilo. Když kontrola zápisu selže, sektor na disku je označen za vadný a použije se místo něj jiný. Uživatel se tak nemusí nic dozvědět. Data o vadných sektorech IMHO nejsou na moderních discích uživatelsky dostupná ani dokumentovaná mimo interní dokumentaci výrobce disků, takže k vadným sektorům se již nikdy nedostanete.
Pozri hdparm
alebo HDAT2. HDAT2 je vlastne DOS s programom HDAT2. Určite by som sledoval parametre S.M.A.R.T či tam nejaký parameter prudko nestúpa. Iste vieš, že ak disk vykazuje chyby môže a nemusí fungovať o nejaký čas. Tiež testovanie môže poškodenému disku skrátiť životnosť. Tieto pokusy sú väčšinou rizikové a môžu ľahko zničiť disk a sú na vlastné riziko.
# badblocks -wsv /dev/sdk Checking for bad blocks in read-write mode From block 0 to 488386583 Testing with pattern 0xaa: done Reading and comparing: done Testing with pattern 0x55: done Reading and comparing: done Testing with pattern 0xff: done Reading and comparing: done Testing with pattern 0x00: done Reading and comparing: done Pass completed, 0 bad blocks found. (0/0/0 errors)A smartctl:
... SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 19 3 Spin_Up_Time 0x0027 153 128 021 Pre-fail Always - 1341 4 Start_Stop_Count 0x0032 088 088 000 Old_age Always - 12560 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 1697 10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 454 191 G-Sense_Error_Rate 0x0032 084 084 000 Old_age Always - 16 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 124 193 Load_Cycle_Count 0x0032 188 188 000 Old_age Always - 36068 194 Temperature_Celsius 0x0022 112 098 000 Old_age Always - 31 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 1 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 1614 - # 2 Short offline Completed without error 00% 1602 - # 3 Short offline Completed: read failure 90% 1592 39801192 # 4 Short offline Completed: read failure 90% 1574 39801192 # 5 Short offline Interrupted (host reset) 90% 385 - 2 of 2 failed self-tests are outdated by newer successful extended offline self-test # 1 ...
Neměl jsi na tom disku taky nějaké obrazy virtuálek? Ptám se proto jestli taková chyba sektoru nemohla vzniknout nějakou kolizí hostujícího a hostovaného OS (přesněji jejich FS). Není to moc pravděpodobné, ale pro jistotu se ptám.
Ne, byl to disk z druhé ruky a na něm byl NTFS, víc jsem nezkoumal. Viz původní dotaz.
Otázka zní, existuje již něco takového? V manuálu k 'badblocks' jsem nic nenašel...Samozrejme že to existuje, aj keď len s vynechaním používania vadného bloku. Neprepíše to nulami ten "pokazený sektor". Napríklad nástroj fsck.ext4 má parametre na prácu s badblocks aby pri čítaní chyby odhalil. Ale logicky ich odhalí len ak mu to vyreportuje elektronika disku, alebo ak sa jedná o chybu čítania metadát chránených checksumom (v prípade silent data corruption). Pre takéto prípady vznikli NextGEN FS ktoré odhalia nekonzistenciu dát pri ich čítaní alebo pri scrube. A v prípade redundantného zápisu poskytnú opravené dáta. Ak chceš ten disk na niečo trochu zmysluplné, tak použi BTRFS s profilom DUP, ako už bolo určite povedané veľa krát.
Samozrejme že to existuje, aj keď len s vynechaním používania vadného bloku.
Na to jsem se ale neptal, o tom vím. Prozatím stačilo přepsat ten sektor nulama a disk zdá se funguje. Momentálně na něm běží f3write, tak uvidíme...
Na to jsem se ale neptal, o tom vím.V tom prípade by som odporučil o presnejšiu formuláciu otázky. Inak ten disk by fungoval aj bez prepísania nulami. Pred pár rokmi som riešil niečo podobné, ale nemal som šťastie že mi disk zahlásil chybu čítania. Liečba bola podobná.
Otázka byla položena naprosto exaktně („existuje utilitka, která vyhledá vadné sektory a pokusí se je přepsat nulama?“). Odpověď na tuto otázku je buď ANO, NE nebo NEVÍM.
Otázka NEZNĚLA:
Nevím, proč tady spousta rozumbradů má tendenci odpovídat na to, na co se je nikdo neptal...
Odpoveď je tým pádom áno, a zabezpečuje ju technológia SMART priamo vo FW disku.
Očividně nemáše pravdu. Člověče, čteš ty vůbec to, na co „odpovídáš“?
A rovno sa opýtam, aký význam má prepísať pár vadných sektorov ak sa chyba na škrknutej platni disku vždy rozlieza?
V tom případě to smysl nemá. To ale je očividně jen jeden z možných scénářů, jak ukazuje tento případ (ano, takový případ jsem řešil před 2r a pak ten disk je na vyhození/na magnety/na elektroniku...)
Za vsetkych pouzivatelov operacneho systemu Windows a GNU/Linux sa Vam chcem uprimne ospravedlnit za traumu, ktora Vam bola sposobena diskutermi na portali abclinuxu.
Ale prd. Jen mi tady soudruh Golis vytýká, že jsem prý dostatečně přesně nespecifikoval otázku. LOL.
Smartctl -t short taky chcípl a smartctl pak hlásil jeden "pendlující" sektor, jinak nic. ... Popravdě, obsah tohoto disku je mi vcelku jedno (prázdný NTFS), ale přemýšlím, jestli by v takovém případě nebylo efektivní mít utilitku, která bude hledat vadné sektory a když je najde, tak se bude snažit přepsat *jenom* ty vadné nulama?Mám dojem, že řešíš přesně to co jsem řešil já nějaký měsíc zpátky.
smartctl -t short
mi taky chcípt. Já jsem ale nezjišťoval vadný sektor pomocí ddrescue, tak jako ty, ale po spuštění smartctl -a /dev/sdb
jsem viděl, že vadný sektor je na pozici, kterou mi to vypsalo v kolonce "LBA_of_first_error". Následně jsem zjistil jméno souboru (pomocí příkazu debugfs
), který se v daném místě nachází. Snažil jsem se daný soubor zachránit. Pak jsem dané místo (vadný sektor) přepsal nulami za pomoci příkazu hdparm --yes-i-know-what-i-am-doing --repair-sector <číslo_sektoru> /dev/sdX
a následně jsem znovu spustil Smartctl -t short
. Znovu to chcíplo, ale už na jiném (vedlejším) sektoru. Pořád to byl ten samý soubor. Takže znovu jsem přepsal nulami a znovu spustil smartctl -t short
. Po přepsání asi 10ti vadných sektorů nulami už konečně short test doběhl do konce. Jestli si dobře vzpomínám, tak se ty vadné sektory po přepsání nulami reallocovaly samotným FW disku a vadné sektory se už (zřejmě) přestaly používat.
Takže stručně řečeno. Utilitku na to nemám - dělal jsem to ručně. Pokud bys to chtěl mít automatizované, tak bys to musel v bashi nebo pythonu naprogramovat. Nepovažuji, ale za šťastné mít tu utilitu jen na zjištění vadného sektoru a přepsání nulami. Spuštění utility by ti zničilo soubor a ty bys neměl informaci o jaký soubor by šlo. Tak když už bys takovou utlitku programoval, tak by bylo dobré, aby nejdříve vypsala jméno souboru, který se nachází v místě vadného sektoru, a až po potvrzení by se vadný sektor přepsal nulami.
PS: řešil jsem to u ext4, tudíž nevím jak bude reagovat NTFS když mu přepíšeš nějaký sektor (nějakého souboru) nulami.
právěže u mě tam byl předtím 1 "pendlující" sektor, ten se při přepsání sektoru nulama změnil na 0Myslím, že u mne to bylo taky tak.
a zároveň narostlo 200 "multi zone error rate" na 1.U mě to bylo stejné. Po nějakém čase se 200 "multi zone error rate" změnilo z 1 na 0.
Podle mě je nejpravděpodobnější vysvětlení, že k žádné realokaci nedošlo, jenom přepsáním sektoru se ho podařilo znovu "naformátovat"...Nevím. Článek říká:
If you check the Current Pending Sector Count SMART parameter of your drive, you will notice a raw value of this attribute. The value indicates the number of sectors waiting to be remapped (reallocated). These sectors are basically damaged storage blocks — bad sectors — on the drive.
These sectors are basically damaged storage blocks — bad sectors — on the drive.
„Basically“. On to ten disk musí nějak zjistit, zda-li je ten sektor opravitelný nebo ne. Problém je v tom, že když jej nepřečte, nemůže jej ani realokovat a ani se nebude pokoušet sektor jen tak přepsat. Teprve ve chvíli, kdy je disku dán příkaz daný sektor přepst se skutečně uvidí. Buď je sektor označený za vadný a použije se náhradní (pokud jsou) a nebo přepis pomůže a pak se použije vesele dál...
hdparm --yes-i-know-what-i-am-doing --repair-sector <číslo_sektoru> /dev/sdXI tohle by mělo fungovat, ale nezkoušel jsem:Nenapadlo mě, že hdparm bude něco takového umět.
sudo dd if=/dev/zero of=/dev/sdX bs=512 count=1 oflag=direct seek=<číslo_sektoru>
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.