Kiintolevyn testaus ennen käyttöönottoa

[Lagittaja]

Kiintolevyjen testaus ennen niiden käyttöönottamista, oli se uusi tai vanha, on erittäin hyvä idea.
Itse kun tässä tuli hankittua muutama kiintolevy ja tehtyä testejä niin ajattelin kirjoittaa aiheesta.

En nyt kuitenkaan lähde kirjoittamaan mitään opasta.
Käytän valmista skriptiä joten lukijalta tämä ei vaadi mitään muita taitoja kuin tiedonhaku ja luetun ymmärtäminen.

Skripti jota käytän on tämä
GitHub - Spearfoot/disk-burnin-and-testing: Shell script for burn-in and testing of new or re-purposed drives
Mitä tämä skripti tekee:

• ajaa SMART short self-test ja long self-test
• ajaa badblocks ohjelman "destructive" moodissa (eli pyyhkii kaiken datan!) joka etsii viallisia blokkeja (sekä tietenkin raportoi niistä)
• kirjoittaa tulokset logitiedostoihin

Itse käytän tätä boottaavasta Ubuntu 16.04.3 LTS imagesta.

Sinun täytyy asentaa smartmontools ja pcregrep. Kaikki muut työkalut/ohjelmat mitä skripti käyttää on asennettuna valmiiksi.​

Ensimmäisenä tarkistan fdisk -l komennolla mitkä tunnisteet kiintolevyillä on.

Yleensä nämä on sda, sdb, sdc ja niin edelleen eli ei ole pakollinen mutta oh well.​

Jos et tiedä mikä on mikä niin tämän voit selvittää esimerkiksi smartctl:llä.

smartctl -i /dev/sda komento kertoo sda kiintolevyn infon kuten valmistajan, mallin, sarjanumeron jne.​

Oletuksena skripti on "dry-run" moodissa eli se ei tee mitään muuta kuin tarkistaa kuinka kauan SMART testi kestää.
Tämä on ihan hyödyllinen info.
Jotta voit käyttää skriptiä testaukseen niin dry-run moodi pitää ottaa pois päältä, disk-burnin.sh tiedoston riviltä 138 vaihdat 1 > 0 ja tallennat tiedoston.

Tämän jälkeen aja komento haluamallasi kiintolevyllä.
sudo ./disk-burnin.sh /dev/sda

Jos haluat ajaa skriptin useammalla kiintolevyllä yhtäaikaa niin avaa useampi terminaali ja pistä pyörimään.
Itselläni tuo skripti pyöri eilen alkuillasta kolmella kiintolevyllä.

Itse kuitenkin käytän tuota skriptiä kuitenkin hieman erilailla.
Skriptin riveiltä 322-327 löytyy testien järjestys.
Oletuksena järjestys on short > long > badblocks > short > long.
Minua ei huvita ajaa tuota long testiä ennen badblocksin ajamista joten poistan rivin 324.

Kun skripti pyörii niin se on ihan fiksua seurata sitä tasaisin väliajoin.
Toisessa terminaali ikkunassa komento smartctl -A /dev/sda
Tuottaa esimerkiksi tällaisen infon.
Kiinnitä huomiota varsinkin ID 5, 196, 197 ja 198 arvoihin.
S.M.A.R.T. - Wikipedia

=== START OF READ SMART DATA SECTION ===
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   ---    Pre-fail  Always       -       125
  3 Spin_Up_Time            0x0027   185   177   ---    Pre-fail  Always       -       5750
  4 Start_Stop_Count        0x0032   099   099   ---    Old_age   Always       -       1721
  5 Reallocated_Sector_Ct   0x0033   200   200   ---    Pre-fail  Always       -       3
  7 Seek_Error_Rate         0x002e   100   253   ---    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   052   052   ---    Old_age   Always       -       35071
 10 Spin_Retry_Count        0x0032   100   100   ---    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   ---    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   099   099   ---    Old_age   Always       -       1405
192 Power-Off_Retract_Count 0x0032   200   200   ---    Old_age   Always       -       300
193 Load_Cycle_Count        0x0032   200   200   ---    Old_age   Always       -       1420
194 Temperature_Celsius     0x0022   119   097   ---    Old_age   Always       -       31
196 Reallocated_Event_Count 0x0032   197   197   ---    Old_age   Always       -       3
197 Current_Pending_Sector  0x0032   200   200   ---    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   ---    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   ---    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   ---    Old_age   Offline      -       0

Jos badblocks testien aikana et huomaa mitään muutoksia kriittisissä SMART arvoissa eikä terminaalissa kun badblocks pyörii ole jotain muuta kuin 0/0/0 errors niin kiintolevy on erittäin suurella todennäköisyydellä täysin ehjä.



Skriptin ollessa valmis löydät skripti tiedoston kanssa samasta kansiosta .log ja .bb tiedoston.
Jos badblocks ei löytänyt viallisia sektoreita niin .bb tiedosto on tyhjä.
Kun taas .log tiedosto sisältää login mitä skripti teki.

P.S. Testin kestosta: WD5000AAKX pyöritti badblocksia 11 tuntia. Uusi 2TB Ironwolf on testauksessa parhaillaan ja näyttäisi siltä että badblocks testi kestää ~32 tuntia. Eräs käyttäjä raportoi että 8TB kiintolevyn (WD Red) badblocks testausta kesti 5 päivää.
Itse SMART testit on kohtuullisen lyhyitä, suurinosa ajasta menee siis badblocks vaiheessa.

 

[hsalonen]

Tässä kannattaa varoittaa, että badblocksin ajaminen SSD:lle on silkkaa tyhmyyttä ja laskee levyn käyttöikää.

 

[Lagittaja]

Joo, eihän siitä ole mitään hyötyä. Saatikka mitään järkeä. Skriptiä ei toki mikään estä käyttämästä mutta silloin pitäisi bb tiputtaa pois ja samalla sitten ylimääräiset SMART testit. En tosin noissakaan näe mitään hyötyä. Uusi SSD? Käyttöön ja kovaa ajoa. Käytetty SSD? Käyttöön ja kovaa ajoa. Ehkä nyt sen short testin voisi huvin vuoksi ajaa mutta ei siihen enää mitään skriptiä tarvita.

Enkä ala erikseensä lisäämään mitään idiootti varoituksia tuohon, jos ei ymmärrä mitä tekee tai ymmärrä mitä luki niin...

 

[Tup3x]

Itse teen hitaan formatoinnin kaikelle ensiksi. Jos sen jälkeen ei näy omituisuuksia smartissa niin sitten vaan käyttöön. Hidasta, mutta simppeliä ja tulee koko levy käytyä läpi.

 

[Lagittaja]

Tietenkin pitää käyttää omaa arviointikykyään että miten, kuinka perusteellisesti ja näin edespäin haluaa testata kiintolevynsä.
Miettiä esimerkiksi sitä mihinkä käyttöön se tulee. Jos nyt jonkun kovon laittaisin vaikkapa pelejä varten niin empä nyt sille välttämättä muuta tekisi kuin molemmat SMART self testit ja käyttöön. Tai videoeditoinnissa tjsp joku scratch levy, sama operaatio.

Ja tietenkin tarkistaa SMART arvot ennen/jälkeen.
​

Mutta sitten kun otetaan se kiintolevy varastokäyttöön tai arkistointiin niin kyllä se nyt pitää perusteellisemmin testata.
Ketjun aloituksen asia tietenkin on se perusteellisempi testaus. Vaikka se kiintolevy nyt ei tulisi kriittiseen käyttöön niin eihän se mitään haittaa testata sitä perusteellisemmin jos on aikaa sille ja itse haluaa tehdä perusteellisemman testauksen.

Tuossa kun aiemmin mainitsin että tuli kiintolevyjä, nämä oli neljä käytettyä ja yksi uusi.
Kaksi noista käytetyistä meni ystävälleni, häntä ei kiinnostanut kunto, ikä, tunnit jne eikä tule niin kriittiseen käyttöön. Mutta minä itse sen halusin varmistaa "kunnolla" että ovat OK, ne kun oli niin vanhoja malleja ja käyttötunnit jo lähenteli 50k niin.. Kuitenkin menivät minun kautta, en halua pistää paskaa eteenpäin ja tuohon testaukseen nyt kuitenkin oli mahdollisuus. (uusi "palvelin" kasattu niin helppo työntää limput siihen ja nurkkaan ruksuttamaan)
Ei niistä mitään vikaa onneksi löytynyt.

Yksi noista käytetyistä sitten tulee olemaan offsite backup joten se lienee päivänselvää että haluan testata sen kunnolla.
Ja viimeinen sitten on vielä odottamassa vuoroaan. Se oli ulkoisessa ja tänään sain aikaiseksi repiä sen sieltä pois. Sen rooli tullee olemaan viikottainen synkronointi palvelimen kanssa.

Ja tuo uusi limppu tulee korvaamaan vanhan WD Blackin joka ostettu 8 vuotta sitten. Se on käynyt ja kukkunut tähän mennessä sen 52-53k tuntia äidilleni kasaamassa HTPC:ssä Win Media Center käytössä eli DVR.
Kuitenkin oli se lähes mikä tahansa tuote niin eiköhän se kylpyamme käyrä kuitenkin päde kohtuullisen hyvin. Eli haluan olla mahdollisimman varma siitä ettei tämä kuulu tuohon early failure ryhmään kaikista yksilöistä.

Tämän kovon suhteen minulla ei ole aikaa tai paljon mahdollisuuksia 1-3kk päästä ruveta puljaamaan takuuvaihtojen kanssa ja sukkuloida sitä dataa ees taas että sen saa lähetettyä takuuseen jos tuossa uudessa olisikin jotain vikaa.
Mieluummin käytän sen pari päivää siihen testaukseen, sitten voi hieman turvallisemmin mielin ottaa sen käyttöön jos tässä testaus vaiheessa ei tule mitään ongelmia vastaan.

Vaikka kuinka se teknologia on mennyt eteenpäin niin kyllähän niitä maanantai kappaleita silti tulee vastaan.
Eli mieluummin löydän sen mädän munan ennenkuin otan käyttöön kuin parin viikon - muutaman kuukauden päästä todeta että voi vittu.

Tästä badblocks vs. "pitkä" formatointi (ts. normaali..) erosta vielä mainitsen sen että bb kirjoittaa+lukee levyn neljään eri kertaan.

Eli neljä drive writes ja kiintolevyn koosta/nopeudesta riippuen monen, monen monta tuntia 100% aktiivisena eli saa kunnon treenit.​

Ja jokaisella kerralla se käyttää eri kirjoituskuviota. Oletuksena 0xaa, 0x55, 0xff ja 0x00. (Eli 1010...., 0101...., 1111.... ja 0000....)

Tässä voi myös käyttää omia kirjoituskuvioita (maks 32bit decimaali) tai random komennolla "random" kirjoituskuvio.​

Ja mahdollisia bittien asentojahan on kaksi, 0 ja 1, niin tämä käy läpi kaikki mahdolliset yhdistelmät.
Normaali formatointi (Vista eteenpäin) kirjoittaa+lukee levyn vain kerran ja kirjoittaa levyn täyteen nollia.
Miten löydät tällä tavalla bitin joka on jäänyt jumiin asentoon 0?
Et mitenkään. Eli tavallinen formatointi on minun mielestäni riittämätön jos sitä käytetään huonojen sektorien löytämiseen.

Enkä edes muista koska viimeksi EN ole käyttänyt quick formattia. No itseasiassa kaksi päivää sitten kun unohdin USB tikun kanssa laittaa ruksin ruuduun, onneksi huomasin sen samantien..​

 

[Fenotype]

En huomannut skriptistä windows notepadilla katsoessani yhtään c optiota, eli scripti ajaa ohjelmaa vain yhtä 4096 blokkia kerrallaan ???

ps. oma rimpsu on badblocks -wvsb 4096 -c 32

Edit: vuonna 2011 Default oli 16 blokkia, arch man sivun mukaan default on 64. Jokatapauksessa -c option asettamalla haluttuun määrään missä tahansa ohjelman versiossa ei silloin jää epäselvyyttä monta blokkia ohjelma käsittelee kerrallaan.

 

[BryciFani]

Itse en ole koskaan mitään testejä ajanut uudella kovalevyllä. Western Digital kovoihin on minulla niin kova luottamus.

Mutta suosittelen sellaista ohjelmaa kuin Hard Disk Sentinel.

Näyttää kaikenlaista tietoa kovalevyistä.

 

[Lagittaja]

Maanantai kappaleita tulee aina. Mieluummin löydän sen viallisen yksilön testaamalla ennenkuin otan sen käyttöön.

 

[TenderBeef]

Onko vinkkejä HDD-testeihin NAS-purkissa? Ei ole muuta konetta johon saisi kiinni.

 

[TheMeII]

Onko vinkkejä HDD-testeihin NAS-purkissa? Ei ole muuta konetta johon saisi kiinni.

ssh:lla kiinni purkkiin ja sitä kautta ajaa jotain softaa?

 

[TenderBeef]

ssh:lla kiinni purkkiin ja sitä kautta ajaa jotain softaa?

Kiitos vinkistä, osaaminen on vaan 0-tasoa, tarvitsisi olla lähes rautalanka-ohjeet, että uskaltaisi tehdä yhtään mitään. NAS on Synologyn DS218+.

 

[IcePen]

Kiitos vinkistä, osaaminen on vaan 0-tasoa, tarvitsisi olla lähes rautalanka-ohjeet, että uskaltaisi tehdä yhtään mitään. NAS on Synologyn DS218+.

Eikö siinä Synologysssa ole sen sisäinnen "kauppa" katso löytyykö sieltä joku sovellus joka tekisi toivomasi tasoisen testin, tuotalähemmäs ei nollatasoa pääse.

 

[TenderBeef]

Eikö siinä Synologysssa ole sen sisäinnen "kauppa" katso löytyykö sieltä joku sovellus joka tekisi toivomasi tasoisen testin, tuotalähemmäs ei nollatasoa pääse.

Pitää tsekata. Tarkennus tuohon 0-tasoon, tarkoitin lähinnä, että verkko/tietoliikenneasioiden osaaminen on lähes 0-tasoa, osaaminen/tieto on vahvasti ohjelmoinnin puolella.. toki yleisosaamista on monenlaisista asioista mutta nuo verkkojutut ovat jääneet pahasti pimentoon.

 

[Pertti Kosunen]

Storage Managerin kautta voi ajaa levyn sisäisiä SMART-testejä tai vaikka ajastaa testit kuukausittain tms. kaikille levyille.

 

[TenderBeef]

Storage Managerin kautta voi ajaa levyn sisäisiä SMART-testejä tai vaikka ajastaa testit kuukausittain tms. kaikille levyille.

Jep. Kaikki ajettu, lyhyt ja pitkä SMART, myös IronWolf Health Test, ja kaikki myös ajastettu. Mutta eihän nuo SMARTit testaa levyn surfacea kuin lukumoodissa, eli kauas jää taakse aloituspostauksessa mainittua badblocks:ia joka tekee kirjoitus+luku testejä eri patterneilla.

Tosin (NAS-levynä) pakolliset varmuuskopiot on oltava muilla levyillä, joten jos posahtaa niin sitten posahtaa, olisi silti ollut kiva testata/ajaa sisään levy.

 

[Lagittaja]

En huomannut skriptistä windows notepadilla katsoessani yhtään c optiota, eli scripti ajaa ohjelmaa vain yhtä 4096 blokkia kerrallaan ???

ps. oma rimpsu on badblocks -wvsb 4096 -c 32

Jäi vastaamatta tähän aikoinaan
badblocks(8) — Arch manual pages

-c number of blocks is the number of blocks which are tested at a time. The default is 64.

Oletushan on siis että badblocks ajaa 64 blokkia yhtäaikaa ellen ymmärtänyt väärin.

Ajattelin nyt vastata kun tuli kaivettua ketju esiin, yhtäkkiä bongannut sitä skriptiä mitä käytin Google haun kautta niin mennään tämän kautta

Jätekatos WD10EZEX menee nyt tässä piakkoin testaukseen, kaveri bongasi töiden ohessa ja kiikutti minulle tarkistettavaksi ennen käyttöönottoa..

 

[BryciFani]

Noniin ProShop lähetti sitten mun 10 TB WD RED kovalevyn pehmustetussa kirjeessä!?? Oli vain ohut kerros kuplamuovia ympärillä.

Nyt tekisi mieli jotain testejä ajaa että onko kovalevyyn tullut vikoja kun noin heikosti oli suojattu paketti.

Vai onko nykyajan kovalevyt niin kestäviä ettei niihin voi tulla vikaa postin käsittelyssä?

Ei noi monen päivän testien kestot kuullosta kivalta ajanvietolta.

 

[Augmented Mutation]

Vai onko nykyajan kovalevyt niin kestäviä ettei niihin voi tulla vikaa postin käsittelyssä?.

Kyllähän ne aika kovia iskuja kestävät (satoja G-voimia), mutta eipä tuossa auta muu kuin katsoa ajan kanssa onko vahinkoa tapahtunut. Laita jokin SMART-ohjelma tarkkailemaan.

Ikävintä kovolle on ottaa isku, kun kiekko on pyörimässä.

 

[BryciFani]

Kyllähän ne aika kovia iskuja kestävät (satoja G-voimia), mutta eipä tuossa auta muu kuin katsoa ajan kanssa onko vahinkoa tapahtunut. Laita jokin SMART-ohjelma tarkkailemaan.

Ikävintä kovolle on ottaa isku, kun kiekko on pyörimässä.

Ah okei. Juu Hard Disk Sentinel on kiva ohjelma.

 

[Lagittaja]

Ah okei. Juu Hard Disk Sentinel on kiva ohjelma.

Aja lyhyt ja pitkä SMART self test. Katso SMART statseja että onko siellä ongelmia.
Tämän jälkeen suosittelen testaamaan sen kiintolevyn kunnolla.

@Augmented Mutation Kiintolevyillä non-operating yleensä 250-350g 2ms sisällä. Tällä WD:llä se on 250g. "Satoja G-voimia" kuulostaa hyvinkin rankalta mutta

Eli tiputus metristä niin 350g deceleration täyttyy 2.8mm pysähdysmatkalla, 250g niin tarvitaan pidempi pysähtymismatka.
Ohut kuplamuovi kirje ei tarjoa tarpeeksi suojaa, yleensähän ne on sellaista 1mm paksuisia. Puhumattakaan siitä että jäykkä kiintolevy ei anna periksi.

En tiedä laskinko oikein mutta 1mm pysähdysmatka olisi tuuheat 900g. Korjatkaa jos olen väärässä.

 

[TenderBeef]

Palaan astialle vuoden jälkeen, pitäisi vaihtaa 6TB levy 12TB:seen ja ajattelin taas levyn testausta ennen käyttöönottoa.

Olisiko hölmöä jos laittaisi uuden kovon NASsiin kiinni ja jakaisi sen verkkoon, windowsilla sitten ajaisi H2testw-softaa kirjoittaen koko levyn täyteen ja lukuvarmistus vielä päälle? Tuo H2testw:hän on kait oikeasti USB/SD-muisteille testi mutta eikös se ajaisi asian ihan HDD:n kanssa?

 

[TenderBeef]

Unohdin mainita, testasin tuossa hiljattain yhden SSD-levyn juuri tuolla H2testw:llä (oli koneessa kiinni USB3-adapterisysteemillä), eli kirjoitus täyteen ja lukutesti. Sen jälkeen tsekkasin SMART:it ettei mitään ihmeellistä. Tiedä sitten oliko järkevää SSD:lle mutta eihän siinä ollut kuin yksi vajaa 500GB kirjoitus-satsi.

 

[Lagittaja]

No mikään ei estä ajamasta sitä mutta sehän on siis tehty pääasiassa muistitikkujen ja -korttien kapasiteetin testaamiseen. Se kirjoittaa randomia dataa jonka se sitten tarkistaa onko se kirjoitettu. Mutta tämähän ei tapahdu sektori tasolla vaan se kirjoittaa vain tiedostoja ja katsoo onko tiedosto kirjoitettu oikein.
Sanoisin että tavallinen/pitkä formatointikin on hyödyllisempi kuin tämä, se sentään etsii niitä huonoja sektoreita.

Lisätään nyt tämä vielä tähän

Tästä badblocks vs. "pitkä" formatointi (ts. normaali..) erosta vielä mainitsen sen että bb kirjoittaa+lukee levyn neljään eri kertaan.
Eli neljä drive writes ja kiintolevyn koosta/nopeudesta riippuen monen, monen monta tuntia 100% aktiivisena eli saa kunnon treenit.Ja jokaisella kerralla se käyttää eri kirjoituskuviota. Oletuksena 0xaa, 0x55, 0xff ja 0x00. (Eli 1010...., 0101...., 1111.... ja 0000....)
Tässä voi myös käyttää omia kirjoituskuvioita (maks 32bit decimaali) tai random komennolla "random" kirjoituskuvio.Ja mahdollisia bittien asentojahan on kaksi, 0 ja 1, niin tämä käy läpi kaikki mahdolliset yhdistelmät.
Normaali formatointi (Vista eteenpäin) kirjoittaa+lukee levyn vain kerran ja kirjoittaa levyn täyteen nollia.
Miten löydät tällä tavalla bitin joka on jäänyt jumiin asentoon 0?
Et mitenkään. Eli tavallinen formatointi on minun mielestäni riittämätön jos sitä käytetään huonojen sektorien löytämiseen.
Enkä edes muista koska viimeksi EN ole käyttänyt quick formattia. No itseasiassa kaksi päivää sitten kun unohdin USB tikun kanssa laittaa ruksin ruuduun, onneksi huomasin sen samantien..

Unohdin mainita, testasin tuossa hiljattain yhden SSD-levyn juuri tuolla H2testw:llä (oli koneessa kiinni USB3-adapterisysteemillä), eli kirjoitus täyteen ja lukutesti. Sen jälkeen tsekkasin SMART:it ettei mitään ihmeellistä. Tiedä sitten oliko järkevää SSD:lle mutta eihän siinä ollut kuin yksi vajaa 500GB kirjoitus-satsi.

No ei tuossa nyt kovin paljon järkeä ollut. SSD:n kontrolleri huolehtii itse viallisista soluista jne. Et saavuttanut tuolla yhtään mitään kuin vähän enemmän kuluneen SSD:n.

Kannattaa myös muistaa että SSD:t käyttäytyvät erilailla verrattuna kiintolevyyn.
Siinä missä kiintolevy voi vain ylikirjoittaa nollan tai ykkösen nollalla tai ykkösellä ja käyttöjärjestelmä ymmärtää miten kiintolevy toimii niin SSD:ssä useampi solu muodostaa sivun (useimmiten 2-16KB) ja useampi sivu (128, 256 tai 512) muodostaa blokin (eli 0.25-8MB). Data kirjoitetaan sivutasolla ja poistetaan blokki tasolla. Ja käyttöjärjestelmä on kaikesta tästä autuaan tietämätön että mitä siellä SSD:llä tapahtuu tai että missä se data oikeasti on.
Eli jos soluissa on jo jotain dataa niin se pitää ensin pyyhkiä isoissa blokeissa ennenkuin voit kirjoittaa sen yhden sivullisen verran dataa.

 

[TenderBeef]

Tiedän kyllä jotain SSD:n eroista HDD:ihin. Eikös kuitenkin koko levykapasiteetin kirjoittaminen täyteen "testaa" ne kaikki saatavilla olevat muistisolut (poislukien ylimääräiset vara-alueet)? Eli jokainen muistisolu "aktivoituu" ja jos jotain häikkää on niin se näkyisi heti SMART-tiedoissa? Näin itse ajattelin.

Tämä löytyi H2testw:n readmestä:

Technical details about the test data
-------------------------------------

H2testw writes data in chunks of 1 megabyte. So even if you choose to
completely fill the media you will end up with up to 1 megabyte of
free space. Although technically not correct H2testw uses the
Windows convention that 1 MByte equals 1024 KByte or 1,048,576 Byte.
In order to avoid problems with the 4 GByte limitation of the FAT file
system, H2testw begins a new data file after each gigabyte (1024
MByte).

Inside a data file each 512-byte sector begins with a 64-bit word (8
byte) containing the offset with regard to the whole data set. It is
stored in little-endian format, least significant byte first.

So the file 1.h2w begins with

00 00 00 00 00 00 00 00,

the next sector with

00 02 00 00 00 00 00 00,

the next with

00 04 00 00 00 00 00 00

and so on. The file 2.h2w begins with

00 00 00 40 00 00 00 00

(offset 1 GByte = 0x40000000).

The rest of each sector is filled with a pseudo random number
sequence using the offset word as a seed.

Eli tämä on huonompi kuin badblocks tai pitkä formatointi? (HDD) Helposti käytettävillä testeillä ei siis tee mitään ja pätevät testit vaativat ropellihattuja? Miten esimerkiksi voisin tuota badblocksia ajella kun tilanne on se, että on vain läppäri, usb-sata-adapteri, nas (synology) jossa toinen levykelkka vapaa? Läppärin boottaus jollain linux-levyllä ja badblocksin ajo 12TB levylle ~10(?) päivää, eli sen verran ilman tietokoneen käyttöä.

Onko SSD:lle sitten mitään järkeviä koko levyn testejä? EDIT2: SMART-testit?

EDIT: Laitoin HDD:n nassiin kiinni ja laitoin extended testin menemään, ~22 tuntia kestää. Pelästyin jo, että onko noin helvetin kovaääninen kun rupesi jyrisemään heti aluksi mutta se taisikin olla vain joku motoriikkatesti aluksi. Ensimmäistä kertaa kovalevyjen kanssa näin SMART-tiedoissa "Helium_Level"-statistiikan.

 

[Lagittaja]

Sanotaan nyt että en minäkään mikään asiantuntija ole NAND flashin suhteen.. Joku voinee korjata jos jotain menee väärin.

Eikös kuitenkin koko levykapasiteetin kirjoittaminen täyteen "testaa" ne kaikki saatavilla olevat muistisolut (poislukien ylimääräiset vara-alueet)? Eli jokainen muistisolu "aktivoituu" ja jos jotain häikkää on niin se näkyisi heti SMART-tiedoissa? Näin itse ajattelin.

Onko SSD:lle sitten mitään järkeviä koko levyn testejä? EDIT2: SMART-testit?

No teoriassa kyllä mutta toisaalta eihän ne muistisolut ole "deaktivoituna" koskaan. Ne on aina jossain asennossa oli se sitten kirjoitusvalmiina tai "käytettynä". (Käsittääkseni se oletus asento on 1 mutta en ole tästä varma, tuli vain vastaan jossain.)

Jos sitä SSD:tä nyt jotenkin haluaa testata niin lähetä sille ATA Secure Erase komento. Tämä kestää sekunteja(/minuutteja?). Voit sitten tarkistaa SMARTit sen jälkeen ja/tai ajaa SMART testejä jos siltä tuntuu.
Secure Erase komento siis resetoi koko SSD:n (kaikki solut) tehdas tilaan eli käytännössä asettaa kaikki solut kirjoitusvalmiiksi. Täten poistaen kaiken mahdollisen datan.
Eli näin ollen "jokainen muistisolu on aktivoitu" ja jos jossain solussa oli jotain "häikkää" eli joku solu ei suostunut toimimaan eli resetoitumaan kirjoitusvalmiiksi niin kontrolleri näkee sen.
Toisaalta taas sitten jotkut asemat kryptaa datan sisäisesti ja Secure Erase vain poistaa sen avaimen mikä riittää siihen tarkoitettuun tehtävään eli datan "poistamiseen" turvallisesti.

Eli tämä on huonompi kuin badblocks tai pitkä formatointi? (HDD)

Kuten sanoin ja lainauksessasi lukee h2testw kirjoittaa random dataa tiedostotasolla ja varmistaa onko data kirjoitettu. Se ei etsi viallisia sektoreita..

Helposti käytettävillä testeillä ei siis tee mitään ja pätevät testit vaativat ropellihattuja? Miten esimerkiksi voisin tuota badblocksia ajella kun tilanne on se, että on vain läppäri, usb-sata-adapteri, nas (synology) jossa toinen levykelkka vapaa? Läppärin boottaus jollain linux-levyllä ja badblocksin ajo 12TB levylle ~10(?) päivää, eli sen verran ilman tietokoneen käyttöä.

No jos tavoitteena on testata se kiintolevy mahdollisimman hyvin kuten aloituksen badblocks skriptillä niin ei, ei niillä helposti käytettävillä testeillä tee oikein mitään. Ikävä kyllä. Tai minä en ainakaan sellaisiin ole törmännyt.

Miten voisit ajella badblocksia? No.. Mikä käyttöjärjestelmä sinulla on? Windows 8/8.1/10 Pro versioista löytyy Hyper-V jolla voit virtualisoida kaikkea jännää. Esimerkiksi nyt vaikka sen Linux käyttöjärjestelmän. Lisäksi Hyper-V:ssä voit myös liittää fyysisiä levyjä niihin virtuaalikoneisiin. If you catch my drift..

Eli kun koneeseen on tuikattu se kiintolevy USB adapterin kanssa niin seikkaillaan Disk Managementtiin, oikea klikataan haluttua limppua ja asetetaan se offline tilaan.
Sitten avataan virtuaalikoneen asetukset, lisätään sille virtuaalinen kiintolevy ja valitaan siihen se fyysinen asema joka nyt löytyy tuosta listasta koska se on offline tilassa.
Tässä esimerkkinä Win10 virtuaalikone. Ulkoinen 500GB limppu (Disk 2) asetettu offline tilaan, valittu Win10 virtuaalikoneen asetuksista ja näkyy sitten Disk 1:senä siinä virtuaalikoneessa mihin se lisättiin.


Toimii tietenkin Linux virtuaalikoneessakin. Tässä heitin sen Debian virtuaalikoneeseeni.
lsblk komennolla listasin block laitteet ennen ja jälkeen sen aseman (HDPmikäsenyttaasolikaan) lisäämisen, niiden välissä piti toki ottaa SSH yhteys uudestaan kun tuota virtuaalisen kiintolevyn lisäystä ei voi tehdä lennosta eli piti käyttää virtuaalikone sammuksissa..


Sitä en kyllä sitten tiedä kuinka helvetin kauan badblocksin ajossa kestää USB SATA sillan yli. Toivottavasti se on edes USB 3.0 malli. USB 2.0 kun on half duplex, 3.0 sentään on full duplex.

Eli sen sijaan että läppäri olisi sinulle käyttökelvottomana 1-2 viikkoa niin läppärin pitää olla käynnissä 1-2 viikkoa.
Onneksi Windows 10:sta löytyy se "pause updates" vaihtoehto 35 päivän ajaksi..

 

[hsalonen]

Tiedän kyllä jotain SSD:n eroista HDD:ihin. Eikös kuitenkin koko levykapasiteetin kirjoittaminen täyteen "testaa" ne kaikki saatavilla olevat muistisolut (poislukien ylimääräiset vara-alueet)? Eli jokainen muistisolu "aktivoituu" ja jos jotain häikkää on niin se näkyisi heti SMART-tiedoissa? Näin itse ajattelin.

Kun ne ylimääräiset vara-alueet voi olla dynaamisia.. Eli voi olla, että kontrolleri on jo havainnut huonoja sektoreita ja piilottanut ne käyttäjältä.

Ongelma on siinä, että sektorin voi kirjoittaa sanotaan vaikka noin 500 kertaa, ennenkuin muistipiiri kuolee. Nyt olet vähintään kirjoittanut 1/500 noista kirjoituskerroista ja vähentänyt levyn elinikää samassa suhteessa. Jos yhden tiedoston kirjoitus kirjoittaa sen saman sektorin 2-5 kertaa, kun se pikkuhiljaa siirtää sitä tiedostoa, niin voipi olla, että levysi on nyt 1% kuolleempi kuin ennen tätä testiä.

Siksi en nyt testaisi tuollaisilla kirjoitusohjelmilla, jotka kirjoittavat levyn täyteen. Ne on pahasta, kun SSD-levyllä on rajallinen määrä kirjoituskertoja.

 

[TenderBeef]

Jos sitä SSD:tä nyt jotenkin haluaa testata niin lähetä sille ATA Secure Erase komento.

Ok, tämä oli hyvä vinkki. Tosin usb-sata-adapterin päässä olevaa levyä ei ainakaan Crucialin oman softan kautta saanut vedettyä tasaiseksi. Lähes kaikki toiminnot eivät olleet valittavissa kun levy ei ollut aidossa sata-portissa kiinni. SMART-testejä sai ajella, ja firmwaren sai päivitettyä.

Miten voisit ajella badblocksia? No.. Mikä käyttöjärjestelmä sinulla on? Windows 8/8.1/10 Pro versioista löytyy Hyper-V jolla voit virtualisoida kaikkea jännää. Esimerkiksi nyt vaikka sen Linux käyttöjärjestelmän. Lisäksi Hyper-V:ssä voit myös liittää fyysisiä levyjä niihin virtuaalikoneisiin. If you catch my drift..

Eipä löydy prota valitettavasti. Virtualboxissa voisi toki kokeilla. Kiitos vinkistä!

Eli sen sijaan että läppäri olisi sinulle käyttökelvottomana 1-2 viikkoa niin läppärin pitää olla käynnissä 1-2 viikkoa.

Ei niin paha mutta liikutettavan koneen kanssa silti vähän hankala.

Kun ne ylimääräiset vara-alueet voi olla dynaamisia.. Eli voi olla, että kontrolleri on jo havainnut huonoja sektoreita ja piilottanut ne käyttäjältä.

Onko tällaisessa tilanteessa SMART-stateissa mitään merkintää? Re-allocated sectors?

Siksi en nyt testaisi tuollaisilla kirjoitusohjelmilla, jotka kirjoittavat levyn täyteen. Ne on pahasta, kun SSD-levyllä on rajallinen määrä kirjoituskertoja.

Tämä on ihan totta. Mutta IMO silti aika pieni kärpäsenpaska tuollainen vajaa 500GB kirjoitus siihen nähden mitä levy kestää. Toki jos ei mitään sillä saavuta niin eipä sitä turhaan kannata tehdä. Ajattelin vain, että koko kapasiteetin kirjoitus voisi ehkä paljastaa mahdollisen DOA-levyn.

Mutta sitten kun otetaan se kiintolevy varastokäyttöön tai arkistointiin niin kyllä se nyt pitää perusteellisemmin testata.

Pälyilin vähän tarkemmin vielä koko ketjua ja tämä kyllä on hyvä kompromissi. Muut levyt joista tehdään backuppeja, niille riittäisi SMART-testit ja käyttöön, backup-kiekot sitten taas kunnon testiin/rasitukseen ennen käyttöönottoa.

 

[TenderBeef]

Laitoin uuden limpun yksin nassiin kiinni ja asennin DSM:n joka automaattisesti teki SHR Btrfs volumen noin vartissa. Kävin poistamassa volumen ja poolin ja tein uuden basic Btrfs volumen (+poolin) ja sieltä asetuksista luontivaiheessa sai vielä valita levyn tarkistuksen. Siellä nyt ajelee "Verifying hard disks in the background" ja "Parity Consistency Check is currently running on Storage Pool 1 and may affect overall system performance." viestein. Eli eiköhän riitä, SMART-testit ja tuo päälle niin riittää. Jatkossa voi vielä ajastaa (SMART-testien kanssa) scrubbing:in joka yhden Btrfs-levyn kanssa osaa tunnistaa bit-rotin/yms. (RAIDillahan onnistuisi korjauskin). Näillä mennään.

Kiitoksia vastauksista. Pitää järjestää sellaiset vararaudat, että jatkossa voi helposti tuota badblocksia ajella varastokäyttöisiin limppuihin.

 

[ztec]

Mä teen yleensä levyn testin badblocksilla aina uusille levyille. Tosi helppo ja kätevä tapa tarkistaa että levy on iskussa. Lisäksi tuon voi tehdä tuhoamatta datoja myöhemminkin. Teen sen käytännössä kaikille levyille kerran vuodessa. Sekä tietty samalla nuo smart checkit. Eli tosi samat käytännöt ollut mulla, mitä tässäkin threadissa on kuvattu.

 

[TenderBeef]

Pitää järjestää sellaiset vararaudat, että jatkossa voi helposti tuota badblocksia ajella varastokäyttöisiin limppuihin.

Ja se aika tuli lähes tasan 2 vuotta myöhemmin. Saksanmaalta tuli tuollainen 12TB WD Elements Desktop USB-kovo joka pitäisi testata kunnolla kun tulisi varastokäyttöön (korvaa 3 eri vanhaa USB levyä, 1TB, 2TB ja 4TB kiekot). Ja nyt on käytettävissä myös vanha läppäri joka joutaa istua olkkarin nurkassa hurisemassa.

On tuo ekan postauksen skripti näköjään muuttunut jonnin verran vuosien aikana, esim. smartit ajetaan eri tavalla ja ei ole tarvetta enää puukotella skriptiä itse (optionseja tullut tarjolle).

Pari kuukautta sitten skriptissä on tehty muutos badblocksin ajamiseen: "Increased memory buffers from 4096 to 8192". Onko tuo ihan ok yleisesti kaikille testattaville levyille? @Fenotype, @Lagittaja, tai kuka tahansa?

Defaulttina badblocksia ajetaan "-e 1 : Abort the badblocks test immediately if an error is found (override this setting with the -x option below)". Riittääkö palautus/vaihtoprosessia varten vain yksi virhe (toki varmasti riippuu valmistajastakin), mitä itse tekisitte, koko testi vai breikkaus ensimmäiseen virheeseen?

 

[ztec]

Pari kuukautta sitten skriptissä on tehty muutos badblocksin ajamiseen: "Increased memory buffers from 4096 to 8192". Onko tuo ihan ok yleisesti kaikille testattaville levyille? @Fenotype, @Lagittaja, tai kuka tahansa?

Onhan tuo ihan ok, kun nykylevyillä tuolla ei liene käytännössä mitään merkitystä, joko levy on kunnossa tai sitten ei. Sinänsä itse tykkään käyttää -b 4096 -c 4096 paria, jolloin noita 4096 byten blokkeja käsitellän 4096 kappaleen ryhmissä. Käytännössä siis 16 megan batcheinä. Tuolla on erityistä merkitystä jos tekee non-destructive testin, kun data luetaan sitten levy testataan ja data kirjoitetaan takaisin. MItä isommissa paloissa tuo homma tehdään, sitä nopeammin tulee valmista. - En muuten ole koskan ajanut tätä testiä SMR levyille non-destructivena, pitäisi joskus ajaa ihan masokismin vuoksi.

Ilman tuota -c parametriä sen oletusarvo on 64, eli b * 64, joka 8192 tavun esimerkin tapauksessa on siis 512 kilotavua.

 

[TenderBeef]

@ztec: Törmäsin tällaiseen kirjoitukseen:

Also, while on the subject of badblocks: for large drives a larger block size must be used, apparently due to some 32 bit limitations in the code. qwertymodo advises to use -b 4096 for drives larger than 2TB. Well, I had to use -b 8192 for the 18TB drives, as I first got errors

But I read somewhere (can't find the source now) that using a block size larger than the drive's sector sizes was bad/pointless, since that somehow wouldn't test the entire disk, i.e. using a 8192 bytes block size on a drive with sector size 4096 bytes meant that only every other 4096 bytes would actually be tested.

Anyone knows if this is correct? If it is, it means I'm really just wasting time running badblocks.

Harmittavasti kukaan ei vastannut tälle käyttäjälle tuolla foorumilla.

 

[TenderBeef]

Ajoin 12TB levylle tuon ekan postauksen scriptin, eli short SMART + Badblocks + extended SMART. Lisäksi ajelin löytämästäni ohjeesta F3 write&read testin ZFS alustetulle levylle ja ZFS scrubbing:in. Lopuksi ajoin vielä short SMART testin ja otin talteen tulostuksen levyn tiedoista (smartctl). Aikaa tähän kaikkeen meni about 2 viikkoa. Eniten aikaa vei odotetusti Badblocks.

 

[=JP=]

Minä ajoin tuon skriptin myöskin 5Tb levylle (2.5" ulkoinen) ja siinä meni noin 6pv, en ihan tarkkaan tiedä, ku en seurannu niin aktiivisesti loppuajasta, mutta puhtaat paperit, joten ei muuta kuin kovaa käyttöä. Mun tuurilla kuiteski laukeaa kuukauden päästä

 

[TenderBeef]

en ihan tarkkaan tiedä, ku en seurannu niin aktiivisesti loppuajasta

Katso lokista jonka se scripti tekee, siellä on eri vaiheiden kohdilla timestampit. Itsellä näköjään meni pelkkään Badblocksiin 7pv 2h. Aika haipakkaa meni oma testini jos sulla 5TB meni ~6pv.

Mun tuurilla kuiteski laukeaa kuukauden päästä

Niinpä. Itse mietin ihan samaa. Eka ajat pari viikkoa testejä ja kaikki ok, sitten teratavuittain tavaraa sisään ja levy kaappiin. Seuraavalla käynnistyskerralla poks...

 

[Vox Humana]

@Lagittaja:
Hyvä ja asiapitoinen ketju. Mukava nähdä että joku jaksaa kirjoittaa noin informatiivisia ja paneutuvia viestejä. Olisi kuitenkin pari kysymystä ja huomautusta:

1)Miten badblocks mahtaa tarkalleen ottaen toimia destructive modessa? Toimiiko se siis niin että se kirjoittaa levylle sillä hetkellä valittuna olevaa bit patternia c*b tavua kerrallaan, ja lukee heti perään saman määrän dataa samasta kohdasta, verraten luettua tavaraa alkuperäiseen, ja siirtyy sitten seuraavaan kohtaan? Jos näin on, niin miten ko. ohjelma varmistaa että luettava data todella tulee fyysisestä levynpinnasta (jota siis on tarkoitus testata) eikä levyaseman sisäisestä välimuistista (disk cache), jonne se todennäköisesti puskuroidaan ennen fyysiselle levylle kirjoitusta? Eikö tässä mielessä olisi järkevämpää käyttää ohjelmaa, joka ensin kirjoittaa koko levyn täyteen alusta loppuun, ja vasta sen jälkeen siirtyy tarkistusvaiheeseen? Kun lukeminen tällöin aloitetaan levyn alusta, niin levyn alkupuolen sektoreille kirjoitettu data on luultavimmin jo pyyhkiytynyt levyvälimuistista, ja luettu data edustaa siten luotettavammin sitä, mitä levyn pintaan todella on tallentunut. Plussana se, että tämä olisi myös nopeampaa kuin kirjoitus- ja lukuoperaatioiden jakuva vuorottelu.

2)Oletko (tai onko joku muu?) koskaan sattunut benchmarkkaamaan badblocksin suorituskykyä ja vertaamaan sitä esim. dd-komennon kirjoitussuorituskykyyn suurella blokkikoolla? Olisi mielenkiintoista kuulla jonkinlainen suhdeluku, kuinka monta kertaa enemmän badblocksilla menee aikaa tietyn osion/partition testaamiseen yhdellä bit patternilla verrattuna siihen aikaan, joka dd:ltä kuluu saman osion ylikirjoittamiseen 0-tavuilla (kun dd:n käyttämäksi blokkikooksi on määritelty bs-parametrilla vaikka 8 MiB).

Tästä badblocks vs. "pitkä" formatointi (ts. normaali..) erosta vielä mainitsen sen että bb kirjoittaa+lukee levyn neljään eri kertaan.
Eli neljä drive writes ja kiintolevyn koosta/nopeudesta riippuen monen, monen monta tuntia 100% aktiivisena eli saa kunnon treenit.
Ja jokaisella kerralla se käyttää eri kirjoituskuviota. Oletuksena 0xaa, 0x55, 0xff ja 0x00. (Eli 1010...., 0101...., 1111.... ja 0000....)
Tässä voi myös käyttää omia kirjoituskuvioita (maks 32bit decimaali) tai random komennolla "random" kirjoituskuvio.
Ja mahdollisia bittien asentojahan on kaksi, 0 ja 1, niin tämä käy läpi kaikki mahdolliset yhdistelmät.
Normaali formatointi (Vista eteenpäin) kirjoittaa+lukee levyn vain kerran ja kirjoittaa levyn täyteen nollia.
Miten löydät tällä tavalla bitin joka on jäänyt jumiin asentoon 0?

3)Onkohan noiden valittujen bittikuvioiden käytölle joku ihan aidosti pätevä peruste, vai olisiko kyse ennemminkin vain siitä, ettei ohjelman kirjoittaja tiedä, miten kovalevyt todellisuudessa sisäisesti toimivat? Minusta vaikuttaa siltä, että ohjelman kehittäjä kuvittelee, että kovalevyn pinta toimii samalla tavalla kuin RAM-muisti jossa jokaisella bitillä on oma kiinteä paikkansa, ja että saman tavun bitit sijaitsevat fyysisesti vierekkäin. Oikeastihan asia ei ole näin.

En tiedä kannattaako tässä nyt alkaa pitämään mitään esitelmää tiedon magneettisesta tallennuksesta kovalevyissä, mutta toteanpahan vain, että ne bittikuviot mitä levyn pinnalle fyysisesti kirjoitetaan, poikkeavat huomattavasti siitä tallennettavasta datasta mitä nämä bittikuviot loogisesti edustavat. Esim. loogista 0-tavua edustava fyysinen data ei oikeasti sisällä pelkkiä nollia, vaan se on tietty sekvenssi nollia ja ykkösiä levyn käyttämän fyysisen enkoodauksen mukaisella tavalla.

Tyypillistä on, että saman tavun bittejä ei myöskään tallenneta fyysisesti peräkkäin, eivätkä loogisesti peräkkäiset tavutkaan välttämättä sijaitse fyysisesti toistensa lähellä. Itse asiassa ainoa mitä voi varmuudella sanoa, on se, että loogisesti samalla sektorilla sijaitseva data sijaitsee myös fyysisesti samalla sektorilla, mutta tämän sektorin sisällä tavujen ja bittien keskinäinen järjestys on täysin kiintolevymallikohtainen parametri, jonka tietää tarkasti vain valmistaja. Tällaista sektorin sisäistä tiedon sekoitusta/hajautusta käytetään siksi, että tiettyyn fyysiseen kohtaan levyn pinnalla osuva mikroskooppinen virhe magnetoituvassa materiaalissa (joka siis muuttaa useita fyysisesti peräkkäisiä bittejä) ei tuhoaisi totaalisesti useita loogisen datan tavuja, vaan jakaantuisi loogisessa datassa mahdollisimman tasaisesti siellä täällä sijaitseviksi yksittäisiksi bittivirheiksi (siis niin, että jokaisessa tavussa on korkeintaan yksi virheellinen bitti), koska tällaiset virheet on helpompi korjata sektoriin sisällytetyllä ECC- eli virheenkorjausdatalla.

Sekin on ehkä syytä todeta, että levyn pinnalle kirjoitettavat fyysiset tavut ovat pidempiä kuin normaalit 8-bittiset loogiset tavut. Jos haetaan vertailukohtaa jostain varhaisista kiintolevyistä, niin niissä loogiset tavut enkoodattiin muistaakseni tyypillisesti 10-14 bitin mittaisiksi fyysisiksi tavuiksi. Tästä enkoodauksesta seurasi mm. sellainen ominaisuus, että yhden bitin eroavaisuus kahden loogisen tavun välillä näkyi yleensä useiden bittien erona vastaavien fyysisten tavujen välillä. Nykyaikaisista kovalevyistä en tiedä minkälaisia enkoodauksia niissä käytetään, mutta pidän mahdollisena, että niiden sektoreita ei edes ole mahdollista jakaa "fyysisen tavun" kaltaisiin vakiopituisiin yksiköihin.

Kaiken tämän seurauksena noiden yllä mainittujen neljän bittikuvion testaaminen ei oikeasti käy läpi "kaikkia mahdollisia yhdistelmiä". Toisaalta mitä tuo kaikkien mahdollisten yhdistelmien testaaminen edes tarkoittaisi? Sen testaamista, että jokainen kohta levyn jokaisessa sektorissa kykenee virheettömästi magnetoitumaan kahteen mahdolliseen asentoon ja siten varastoimaan joko fyysisen nollan tai ykkösen? Pahoin pelkään, että yksikään moderni kovalevy ei tällaiseen pysty. Nykyaikaisilla tiedon tallennustiheyksillä on väistämätöntä, että osa levyn pintaan kirjoitetuista fyysisistä biteistä tallentuu aina väärin. Mutta sen takia jokaiseen sektoriin tallennetaan myös ECC-dataa, jolla nämä virheelliset bitit pystytään korjaamaan oikeiksi, eivätkä ne siksi koskaan näy levyn käyttäjälle asti.

No, tulihan tässä nyt kuitenkin jonkinlainen lyhyt esitelmä pidettyä kovalevyjen sisäisestä toiminnasta, vaikka ei aluksi ollutkaan tarkoitus. Toivottavasti edes joku jaksaa lukea, ettei mene ihan hukkaan.

 

[Vox Humana]

@ztec: Törmäsin tällaiseen kirjoitukseen:

Also, while on the subject of badblocks: for large drives a larger block size must be used, apparently due to some 32 bit limitations in the code. qwertymodo advises to use -b 4096 for drives larger than 2TB. Well, I had to use -b 8192 for the 18TB drives, as I first got errors

But I read somewhere (can't find the source now) that using a block size larger than the drive's sector sizes was bad/pointless, since that somehow wouldn't test the entire disk, i.e. using a 8192 bytes block size on a drive with sector size 4096 bytes meant that only every other 4096 bytes would actually be tested.

Anyone knows if this is correct? If it is, it means I'm really just wasting time running badblocks.

Harmittavasti kukaan ei vastannut tälle käyttäjälle tuolla foorumilla.

Mahtaisiko tuo lainaamasi kirjoittaja viitata tämän ketjun eniten ääniä saaneeseen vastaukseen?

With regards to the -b option: this depends on your disk. Modern, large disks have 4KB blocks, in which case you should set -b 4096. You can get the block size from the operating system, and it's also usually obtainable by either reading the disk's information off of the label, or by googling the model number of the disk. If -b is set to something larger than your block size, the integrity of badblocks results can be compromised (i.e. you can get false-negatives: no bad blocks found when they may still exist). If -b is set to something smaller than the block size of your drive, the speed of the badblocks run can be compromised. I'm not sure, but there may be other problems with setting -b to something smaller than your block size, since it isn't verifying the integrity of an entire block, it might still be possible to get false-negatives if it's set too small.

En kyllä ihan hirveästi antaisi painoarvoa sille mitä tuossa sanotaan. Tulee jotenkin sellainen vaikutelma ettei kirjoittaja itsekään kovin hyvin tiedä mistä puhuu, sillä jos tietäisi, niin hän perustelisi väitteensä jotenkin. Kyseessä voi olla puhtaasti kirjoittajan oma yksityisajattelu, joka on seurausta jostain väärinkäsityksestä. Muutenkin tuolla nuo aloittajan kysymyksiin tulleet vastaukset ovat aivan ristiriitaisia keskenään: yksi puhuu fyysisistä sektoreista, toinen loogisista sektoreista, kolmas tiedostojärjestelmän varausyksiköistä. Kaikilla vastaajilla näyttäisi olevan vähän erilainen käsitys asioista ja ylipäätään porukka puhuu toistensa ohi. Veikkaan myös että tuo eniten ääniä kerännyt vastaus on saanut suurimman osan äänistään vain siksi, että se yrittää muotoilulla ja muilla ulkoisilla keinoilla vaikuttaa "autoritatiiviselta" ja analyyttisemmältä kuin se onkaan.

Lopullinen totuus kysymykseen taitaa löytyä vain siltä, joka on lukenut läpi badblocksin lähdekoodin, ymmärtää sen täysin, ja tuntee myös koodissa käytettyjen käyttöjärjestelmäfunktioiden toiminnan perusteellisesti. Vain tällöin voi varmuudella sanoa, millaisia ATA/AHCI-komentoja kovalevyn komentopuskuriin lopulta päätyy, ja minkälaisen mankelin läpi data kulkee siirtyessään badblocksin paikallisista puskureista kovalevylle ja toisinpäin. Voi olla että pienemmällä vaivalla kirjoittaisi oman ohjelman, joka toiminnallisuudeltaan vastaa badblocksia juuri sen oman käyttötapauksen osalta.

Ehkä kannattaa kuitenkin muistaa, että badblocks on jo kohtuullisen kauan kuulunut Linuxin vakiovarustukseen (ainakin näin olen ymmärtänyt), joten on vaikea uskoa että siinä olisi mitään niin ilmeistä bugia, että "väärän" blokkikoon spesifioiminen saisi sen antamaan virheellisiä tuloksia. Sen takia en kauheasti hermoilisi tämän asian kanssa. Se mikä itseä enemmän mietityttää on ylempänä mainitsemani kovalevyn sisäinen välimuisti ja sen vaikutus tulosten luotettavuuteen. Miten badblocks ottaa sen huomioon? Kutsuuko se jotain sellaista käyttöjärjestelmäfunktiota joka saa asiaankuuluvan ajurin lähettämään kovalevylle komennon välimuistin disabloimiseksi? Jos kyllä, niin voidaanko olla varmoja siitä, että kaikki kovalevyt varmasti noudattavat tätä komentoa yhtäläisesti?

Itse eksyin tähän ketjuun juurikin siksi, että hakusessa olisi luotettava kovalevy varmuuskopiointikäyttöön, ja sen testaaminen ennen käyttöönottoa olisi varmaan järkevää. Tällä hetkellä parhaalta testimenetelmältä tuntuisi kirjoittaa levy ensin täyteen jotain tunnettua dataa, minkä jälkeen luetaan levy sektori sektorilta läpi ja verrataan luettua alkuperäiseen. Tämän lukuvaiheenhan voi periaatteessa tehdä badblocksin read only -moodilla, mutta se on omassa tapauksessani vielä vähän auki, mikä olisi paras tapa kirjoittaa levy täyteen. Joku dd-komentoa hyödyntävä kikkakolmonen voisi mahdollisesti tulla kyseeseen jos vain kirjoitusnopeuden saa pysymään siedettävänä, mutta ei jonkinlainen itsekoodattu pikkutyökalukaan liene poissuljettu vaihtoehto...

 

[ztec]

@Lagittaja:
1)Miten badblocks mahtaa tarkalleen ottaen toimia destructive modessa?

Et selvästi ajanut sitä koskaan? Destructive mode on lineaarinen, käy koko levyn läpi per passi, non-destructive taas menee vain lohko kerrallaan eteenpäin suorittaen kaikki operaatiot.

2) Oletko (tai onko joku muu?) koskaan sattunut benchmarkkaamaan badblocksin suorituskykyä ja vertaamaan sitä esim. dd-komennon kirjoitussuorituskykyyn suurella blokkikoolla?

Ei käytännössä mitään eroa, kun on kerran puskuroitua menoa. Voihan tuon saman asian tehdä millä tahansa muullakin sovelluksella. Mä olen joskus käyttänyt omaa softaa joka käyttää pseudo-randomia patternia, koska halusin varmistua siitä, että dataa ei voi pakata / cheatata mitenkään.

3)Onkohan noiden valittujen bittikuvioiden käytölle joku ihan aidosti pätevä peruste, vai olisiko kyse ennemminkin vain siitä, ettei ohjelman kirjoittaja tiedä, miten kovalevyt todellisuudessa sisäisesti toimivat? Minusta vaikuttaa siltä, että ohjelman kehittäjä kuvittelee, että kovalevyn pinta toimii samalla tavalla kuin RAM-muisti jossa jokaisella bitillä on oma kiinteä paikkansa, ja että saman tavun bitit sijaitsevat fyysisesti vierekkäin. Oikeastihan asia ei ole näin.

Juuri näin se oli. Mutta ei ole enää.

Edit lisätään tähän MFM linkki niille jotka ei vaan muista:

Modified frequency modulation - Wikipedia

en.wikipedia.org

 

[ztec]

Ehkä kannattaa kuitenkin muistaa, että badblocks on jo kohtuullisen kauan kuulunut Linuxin vakiovarustukseen (ainakin näin olen ymmärtänyt), joten on vaikea uskoa että siinä olisi mitään niin ilmeistä bugia, että "väärän" blokkikoon spesifioiminen saisi sen antamaan virheellisiä tuloksia. Sen takia en kauheasti hermoilisi tämän asian kanssa. Se mikä itseä enemmän mietityttää on ylempänä mainitsemani kovalevyn sisäinen välimuisti ja sen vaikutus tulosten luotettavuuteen. Miten badblocks ottaa sen huomioon? Kutsuuko se jotain sellaista käyttöjärjestelmäfunktiota joka saa asiaankuuluvan ajurin lähettämään kovalevylle komennon välimuistin disabloimiseksi? Jos kyllä, niin voidaanko olla varmoja siitä, että kaikki kovalevyt varmasti noudattavat tätä komentoa yhtäläisesti?

Noi on kaikki oikein hyviä kysymyksiä. Koska nykyiset "levyt" on käytännössä tietokoneita, jotka tekee "jotain" siellä pimeässä pellin alla, niin tuosta ei voi olla mitenkään varma että toimii oikein. Juuri siksi käytin itse sitä pseudo-patterni testiä, koska halusin varmistua siitä, ettei tuloksia voi edes tahallisesti yrittämällä väärentää. Onhan tuo selvää, että mm. SSD:t eivät toimi "puhtain paperein", kun on mm. TurboWrite tekniikkaa ja muuta joka nimenomaisesti on luotu feikkaamaan levyn suorituskykyä puskuroimalla dataa. Sama pätee tietysti myös SMR levyihin. Jne.

Juuri siksi sanoinkin että kannattaa ajaa levyn oma self-test ja sen lisäksi badblocksilla yksi patterni (ihan sama mikä) destructivena. Tämän lisäksi ajan yleensä vielä samassa sarjassa smarterasen ja trimmin jos on tarkoitus tyhjentää device. Mikään noista ei takaa mitään tulosta, mutta jos jotain on rikki niin pitäisi (!) jäädä kohtuullisella todennäköisyydellä kiinni, mutta ei aina tietenkään jää. Sekä tuokaan ei takaa, että kaikki data olisi levyltä tuhottu. Vaikeita asioita nämä on, kun kerran levyt on niitä blackboxeja.

Ainakin noissa suuremman kapasiteetin levyissä niin HDD:t kuin SSD:tkin on badblockseja ja rikkinäisiä alueita ja muistisoluja vaikka kuinka. Ne on vaan maskattu piiloon. Tästäkin taisin pistää jossain vaiheessa hyvän linkin. Jotkut tutkijat olivat autistisella ajoitus-testauksella selvittäneet sen, että levyt piilottelee totuutta. Mutta toinen kysymys on sitten se, että onko sillä jotain väliä. Se että ne on osittain rikki, on vain uusi normaali kun halutaan halvempaa ja suurempi-tiheyksisistä tallennusta.

 

[Vox Humana]

Et selvästi ajanut sitä koskaan? Destructive mode on lineaarinen, käy koko levyn läpi per passi, non-destructive taas menee vain lohko kerrallaan eteenpäin suorittaen kaikki operaatiot.

Oikein arvattu, en ole ennen käyttänyt sitä, siksi kysyn. Mutta onko jokainen pass jaettu erilliseen kirjoitus- ja lukuvaiheeseen, vai onko nämä vaiheet lomitettu niin että ne vuorottelevat c*b-kokoisissa lohkoissa?

Ei käytännössä mitään eroa, kun on kerran puskuroitua menoa.

Veikkaisin että puskuroinnista huolimatta kirjoitus- ja lukuoperaatioiden vuorottelu saattaa heikentää vähän suorituskykyä, kun levyaseman lukupää joutuu tekemään edestakaista liikettä.

Juuri näin se oli. Mutta ei ole enää.

Edit lisätään tähän MFM linkki niille jotka ei vaan muista:

Meinasin juuri ennen edittiäsi kommentoida, että olikohan juttu edes PC-koneiden ensimmäisissä, MFM-enkoodausta käyttävissä asemissa silloin 80-luvun alussa ihan noin, mutta näköjään oli. Tosin MFM:ssäkään peräkkäiset databitit eivät sijaitse fyysisesti suoraan peräkkäin (siis siinä mielessä että ne voisivat "vuotaa" toistensa puolelle), koska välissä on kellobittejä, aivan kuten tuosta linkkaamastasi artikkelistakin ilmenee.

Ainakin noissa suuremman kapasiteetin levyissä niin HDD:t kuin SSD:tkin on badblockseja ja rikkinäisiä alueita ja muistisoluja vaikka kuinka. Ne on vaan maskattu piiloon.

On varmasti jonkin verran, mutta kannattaa ehkä kuitenkin muistaa ero viallisten sektorien ja yksittäisten virheellisten bittien välillä. Virheelliset bitit pystytään korjaamaan lennosta ECC-koodeilla, kun taas kokonaisten viallisten sektoreiden tapauksessa ECC-korjaus ei riitä ja pitää ottaa käyttöön varasektoreita (=uudelleensijoittaa sektorit). Nykyisten suurten tallennustiheyksien aikakaudella yksittäiset bittivirheet ovat luultavasti useita kertaluokkia yleisempiä kuin vialliset sektorit, koska en usko että millään valmistusmenetelmällä pystyttäisiin tuottamaan kovalevyn pintaan niin homogeenista magnetoituvaa kerrosta, että siinä ei olisi edes mikroskooppisen pieniä virheitä/poikkeamia. Näihin ECC:llä korjautuviin bittivirheisiin verrattuna kokonaiset vialliset sektorit ovat huomattavasti harvinaisempia.

Jotkut tutkijat olivat autistisella ajoitus-testauksella selvittäneet sen, että levyt piilottelee totuutta.

Tästä olisi mielenkiintoista lukea lisää. Sattuisiko löytymään linkkiä johonkin asiaa koskevaan uutiseen tai jopa alkuperäiseen tutkimukseen?

Ajoitustestaukselle vaihtoehtoinen menetelmä voisi olla joku herkkä mikrofoni tai värähtelysensori. Sellaisella voitaisiin havaita kovalevyn lukupään odottamattomat liikkeet merkkinä siitä, että joku sektori ei nyt fyysisesti sijainnut ihan siellä missä sen kaiken järjen mukaan pitäisi sijaita. Muistan kun vuosia sitten pyyhin dd:llä tyhjäksi kierrätykseen meneviä vanhoja IDE-kovalevyjä, ja aina välillä levystä kuului *klik*. Arvelen että nämä äänet olivat merkkinä viallisista sektoreista ja syntyivät siitä, kun levyn lukupään oli välillä pakko hypätä levyn laidalla sijaitsevalle varasektoreita sisältävälle alueelle. (Ideaalitapauksessahan dd:llä kirjoittamisesta ei pitäisi syntyä minkäänlaisia lukupään liikkeisiin liittyviä ääniä, koska se kirjoittaa sektorit LBA-numerojärjestyksessä, ja peräkkäiset LBA-numerot omaavilla sektoreilla on tapana sijaita myös fyysisesti peräkkäin tai vähintäänkin vierekkäisillä urilla.) Nykyään tällainen viallisten sektorien havaitseminen paljain korvin kuuntelemalla ei taitaisi enää onnistua, koska kovalevyvalmistajat eivät oletettavasti enää sijoita varasektoreita levyn reunaan vaan hajauttavat ne tasaisemmin ympäri levyä.

Yleisellä tasolla nämä kovalevyjen harrastamaan totuudenpiilotteluun liittyvät kysymykset ansaitsisivat enemmän huomiota. Olen törmännyt netissä useamman kerran väitteisiin, että varsinkin Western Digitalin levyt vääristelisivät SMART-parametreja valmistajan eduksi ja jättäisivät raportoimatta ongelmista viimeiseen asti, kun data vain vielä on jotenkin luettavissa. Olen siinä käsityksessä, että erityisesti "reallocated sector count"-parametri olisi tällaisen vääristelyn kohteena, ja siinä ei lainkaan huomioitaisi niitä sektoreita, jotka on ehditty uudelleensijoittaa "ajoissa", ts. levyn firmis on vielä onnistunut pelastamaan niiden sisältämän datan (kenties useilla lukuyrityksillä). Väitetysti WD:n levyistä ainoastaan RAID-käyttöön tarkoitetut raportoisivat ongelmista totuudenmukaisesti SMART-parametreissa.

Se että ne on osittain rikki, on vain uusi normaali kun halutaan halvempaa ja suurempi-tiheyksisistä tallennusta.

Tämä jos mikä on pirullinen trendi. On oikeasti monia käyttökohteita, joissa tallennusvälineen kaikkein tärkein ominaisuus olisi luotettavuus, johon nähden esim. kapasiteetti, hinta per gigatavu ja luku-/kirjoitusnopeus ovat toisarvoisia parametreja, mutta tämä ei tunnu valmistajia kiinnostavan. Kun teollisuus keskittyy optimoimaan tuotteitaan kapasiteetti ja hinta edellä, niin samalla jää huomaamatta, että saattaisi olla olemassa myös sellainen markkinasegmentti, jossa valmistusteknologian kehittymisen avaamat mahdollisuudet kannattaisi käyttää ennemmin tuotteiden toimintavarmuuden parantamiseen.

 

[Griffin]

Seagaten läppärilevyt on ainankin itsellä välillä jääneet kiinni kusettamisesta.
Eli levy on ollut huonossa kunnossa. Kerran jopa SMART ilmolitti virheestä.
Levy kiinni toiseen koneeseen ja chkdsk /f /r ja seuraavana päiväna smart olikin ns puhdas.

Toki levyn cloonaus oli hyvin hidas operaatio (onnistui kuitenkin) ja kun levyä kuunteli, niin selkeästi kuuli välillä, miten kukupäitä rankaistiin rajusti kaibrointi asemassa.
Jotkut levyt on myös olleet mukamas ihan kunnossa ja silti osa sektoreista on lukeutunut mielettömän hitaasti.

Yksi pöytäkoneessa ollut seagaten normi /SSD hybridi korruptoi itsensä aina lyhyessä ajassa ja kaikki muut testit menivät läpi puhtaasti, paitsi valmistajan pitkä testi keksi ilmoittaa, että kiikuta levy vaihtoon..

Itse testaisin mekaanisen levyn siten, että crystal diskinfolla katsoo SMARTIN ja jollain ohjelmalla ajaa pinnan luku ja hakutestin ja kasoo, että sen antama tulos on ko levylle tyypillinen. Jos lukunopeus heittelee kummallisesti, niin silloin on tulossa ongelmia..

 

[ztec]

Oikein arvattu, en ole ennen käyttänyt sitä, siksi kysyn. Mutta onko jokainen pass jaettu erilliseen kirjoitus- ja lukuvaiheeseen, vai onko nämä vaiheet lomitettu niin että ne vuorottelevat c*b-kokoisissa lohkoissa?

Destructivessa ei vuorotella, non-destructivessa vuorotellaan tietenkin, koska muuten homma ei toimisi.

On varmasti jonkin verran, mutta kannattaa ehkä kuitenkin muistaa ero viallisten sektorien ja yksittäisten virheellisten bittien välillä. Virheelliset bitit pystytään korjaamaan lennosta ECC-koodeilla, kun taas kokonaisten viallisten sektoreiden tapauksessa ECC-korjaus ei riitä ja pitää ottaa käyttöön varasektoreita (=uudelleensijoittaa sektorit). Nykyisten suurten tallennustiheyksien aikakaudella yksittäiset bittivirheet ovat luultavasti useita kertaluokkia yleisempiä kuin vialliset sektorit, koska en usko että millään valmistusmenetelmällä pystyttäisiin tuottamaan kovalevyn pintaan niin homogeenista magnetoituvaa kerrosta, että siinä ei olisi edes mikroskooppisen pieniä virheitä/poikkeamia. Näihin ECC:llä korjautuviin bittivirheisiin verrattuna kokonaiset vialliset sektorit ovat huomattavasti harvinaisempia.

Juuh, ovat toki harvinaisempia, mutta silti niitä on valtavat määrät jokaisessa levyssä, joten se on "täysin normaalia". Että levyssä on badsectoreita ja paljonkin. Tuo käytiin hyvin läpi tutkimuksessa, ja toisaalta ei se sinänsä yllätä, se oli myös luonnollisesti täysin arvattavissa.

Western Digitalin levyt vääristelisivät SMART-parametreja valmistajan eduksi ja jättäisivät raportoimatta ongelmista viimeiseen asti, kun data vain vielä on jotenkin luettavissa.

Blue levyt tekevät juuri tuota. Ja siitäkin huolimatta, että data ei ole enää edes luettavissa, silti eivät anna smartissa Erroria. Ihan sama homma oli sen Toshiban SSD:n kanssa myös. Se on kunnossa, kaikki data ei vaan ollut luettavissa.

Olen siinä käsityksessä, että erityisesti "reallocated sector count"-parametri olisi tällaisen vääristelyn kohteena, ja siinä ei lainkaan huomioitaisi niitä sektoreita, jotka on ehditty uudelleensijoittaa "ajoissa", ts. levyn firmis on vielä onnistunut pelastamaan niiden sisältämän datan (kenties useilla lukuyrityksillä).

Ihan sama kokemus kokemusperäisesti noiden levyjen osalta. Mulla on noita ehjiä mutta rikkinäisiä levyjä kymmenittäin.

Tämä jos mikä on pirullinen trendi. On oikeasti monia käyttökohteita, joissa tallennusvälineen kaikkein tärkein ominaisuus olisi luotettavuus, johon nähden esim. kapasiteetti, hinta per gigatavu ja luku-/kirjoitusnopeus ovat toisarvoisia parametreja, mutta tämä ei tunnu valmistajia kiinnostavan. Kun teollisuus keskittyy optimoimaan tuotteitaan kapasiteetti ja hinta edellä, niin samalla jää huomaamatta, että saattaisi olla olemassa myös sellainen markkinasegmentti, jossa valmistusteknologian kehittymisen avaamat mahdollisuudet kannattaisi käyttää ennemmin tuotteiden toimintavarmuuden parantamiseen.

Siksi tiedot tallennetaan virheenkorjausdatan kanssa ja useammalle levylle ja varmistetaan toisaalle. Joten jos data on tärkeää, ei se mihinkään katoa. Ei vaan pidä luottaa yksittäiseen halpaan roska-mediaan.