Klonas även dåliga sektorer vid en kloning?

Permalänk
Medlem

Klonas även dåliga sektorer vid en kloning?

Jag har en hårddisk A som jag ska klona till B
Vid kloningen får jag reda på att A innehåller dåliga sektorer/area men väljer att fortsätta ändå.
Kommer hårddisk B då även ha dåliga sektorer?

Permalänk

Det är ju inte sektorn som klonas utan den data som lagrats i sektorn. Korrupt data kommer att klonas till oskadad sektor skulle jag säga.

Permalänk
Medlem

Snurrdisk med oläsliga sektorer så kommer det ingen data ur de trasiga sektorerna och sedan är det upp till Kloningsprogrammet hur det hela hanteras - En plain 'dd' kopiering så avbryts kopieringen när sektor inte kan läsas, på samma sätt som det blir IO-fel när ett program försöker läsa en trasig sektor.

Med program som ddrescue så kan man välja strategier i hur de svårlästa sektorer skall hanteras - hur många gånger de skall försöka läsas om igen etc. - sådana program bruka jobba med att jobbiga sektorer tar man sist (då det tar väldigt mycket tid per läsförsök) och läser dom lätta först just för att ta så mycket det går på så kort tid som möjligt då man kanske har väldigt kort tid på sig innan det havererar helt.

Tex. ddrecue (i linux-miljö) när den läst alla 'lätta sektorer går sedan tillbaka till de svåra och saxar mellan olika delar för att ta läsbara bitar som möjligen är mellan sektorer som inte kan läsas och sedan provar många gånger på de oläsliga sektorerna i många olika mönster och läsarmarsrörelser för att nyttja överslängar och annat när det styr in sig på spåren då det ibland när det åker lite på kanten i spåret och få något bättre S/N och några färre felaktiga bitar kan lyckas att läsas - just snurrdiskar är tacksamma att man kan prova flera hundra gånger, ja tusentals gånger på samma sektor och inte sällan kan det till slut går att läsa korrekt en gång - det räcker för ddrescue. Det finns de som låtit ddrescue läsa på snurrdiskar i halvår med början 30% lyckade sektorer men efter 6 månader fått ut 98%!!

Flashmedia som SSD däremot...(och WD-RED... men det är annan historia), brukar istället ge konsekvensen att hela disken hänger sig hårt och måste startas om med en power off/on innan man kan läsa vidare igen, och i somliga fall kan det vara den slutliga döden för SSD. ddrecue är som tur smart och försöker inte läsa på samma ställe igen vid nästa läsförsök och med diskdocka och man hela tiden slår av och på med strömbrytare var gång det hänger sig så har man stor chans att ändå rädda diskinnehållet till stor del.

Snurrdiskar och SATA-SSD har väldigt bra felkoll att datat som levereras är korrekt - eller så levereras ingen data alls - det läses inte ut några sektorer med korrupt data ur snurrdisk/SATA-SSD (om man inte kör idag väldigt exotiska program som använder gamla ATA-kommandon för att ta sig förbi spärrningen och läser ut datat från disk-RAM som det såg ut när det blev inläst - tveksamt om det ens går med dagens diskar) - går det inte att läsa alls så får kloningsprogrammet ersätta LBA-nummret med en tom '0'-värde sektor så länge eller på annat sätt markera att den positionen inte håller någon data som kommit ifrån snurrdisken.

I ddrescue och på linux så blir det sk. 'hål' i diskimagen - LBA-nummer som inte är kopplad till någon fysisk sektor alls och forcerar man att läsa dessa LBA-nummer ändå som kommer den att emuleras och innehålla värde med bara '0' i sektorn.

Faktum är att felkollen är så bra på snurrdiskar och SATA-SSD att det är större risk för oupptäckta fel när datat transporteras över SATA-sladden pga. elektroniska störningar och brus än att en snurrdisk skulle leverera en sektor med korrumperad data oupptäckt.

Risken att en snurrdisk levererar felaktig data oupptäckt ligger på ungefär 1*10^-21 bit - dvs. ungefär 1 - 10 miljon färre gånger än att den skulle ha ej läsbara sektorer för att det är ej rättningsbara sektorer.

När det gäller SD-minne och många USB-stickor så är det dessvärre mycket sorgligare historia - dessa har ingen integritetskoll och spärrar inte för misslyckade läsningar och kan leverera korrupta sektorer utan att det är något alls som varnar för det - det finns förvisso felkoll på flashchip-nivå och som skriker i högan sky när det läser korrupta block - men det finns ingen i SD-minnes:s överföringsprotokollet som kan överföra den informationen eller spärra dataöverföringen när det läser ut fel, utan det blir hittepåvärden som blandas in i all korrekta data - ger så kallat 'silent error' - Allra värsta sortens fel...

Det enda sättet att få koll på om datat är korrekt eller inte på sådan media - förutom att se sina jpeg-bilder bara renderas till häften och en grön streck tvärs över bilden och sedan inget mer - är att alla filer hashas med hashsumma sparad någonstans eller använda filsystem som har CRC eller checksumma på alla sektorer på filsystemet som används på mediat - vilket idag ger att det är bara ZFS [1] och BTRFS [2] och möjligen ReFS [3] som kan användas om man vill ha koll om sektorerna man läser ut är korrekta - filsystemet får göra det jobbet på SD-minnen och USB-stickor som annars görs internt automagiskt i snurrdisk och SATA-SSD..

- och samtidigt skall man komma ihåg att felupptäcksalgoritmerna i snurrhårddiskar och SSD är _mycket_ bättre än vad både BTRFS och ZFS klarar i sina standardlägen och man måste slå på SHA256 i ZFS (dvs. man slår på dess automatiska deduplikation med allt vad det innebär i prestandaförluster och RAM-förbrukning i ZFS) och blake2 eller SHA256 i den allra senaste versionen av BTRFS (varav SHA256 går 8 ggr långsammare än CRC32C medans blake2 'bara' kostar dubbelt i tid) för att hamna i samma nivå och förbi i felupptäcktsförmåga som hårddiskar i att upptäcka korrupta sektorer. - kort sagt snurrdiskars och SATA-SSD felupptäckande av korrupta sektorer är väldigt bra fast de inte använder sig av kryptografisk tåliga Hashvärden som blake2 och SHA256.

[1]
Som i sin vanliga 'default mode' använder Fletcher-checksumma och har rätt dålig felupptäcksförmåga vid fler bitfel än 2 bit fel per 4k-sektor och missar 2-3% av felen när datat är påverkad av vitt brus med BER i 10^-5 i feltakt) - krasst sett så kommer ZFS checksummekoll aldrig någonsin att se ett fel så länge snurrdiskens och SATA-SSD samt SATA-överföringens felkoll fungerar.

När det gäller SD-minnen och USB-stickor så är det dock annan femma, eftersom det inte finns felkoll alls ända från lagringen, där kan det upptäckas om det är riktigt dålig läskvalitet ur flashminnena - men BTRFS kommer då att hitta fler fel i samma situation, många fler....

[2]
Som använder iSCSI:s CRC32C som är ca 10000 ggr bättre upptäcksförmåga av brusfördelade bitfel än SATA:s IEEE 802.3 CRC32, med 100% upptäcktsförmåga upp till 6 bit fel per 655-bit för CRC32C och IEEE 802.3 CRC32 klarar 100% upptäckt till 6 bit fel för 33 byte och båda klarar till 100% 4 bit fel per 4k-sektor med skillnaden att iSCSI kan behålla det till 268 kBytes storlek medans CRC32 når bara upp till 11 kByte

Både ZFS och BTRFS har 4Kbyte-block som minsta blockstorlek.

[3]
ReFS används så lite idag och så svårtillgängligt (kräver server och Enterprise-licenser av windows för att kunna formatera mediat) att det inte är någon filsystem man kan räkna med i någon allmän användning - det är numera en nisch-filsystem.