13Aug
De functie 'schijf verifiëren' is geweldig om ervoor te zorgen dat uw versverbrande schijf goed is verlopen, maar hoe werkt deze precies? De SuperUser van vandaag Q & Een bericht heeft het antwoord op de vraag van een nieuwsgierige lezer.
De vraag van vandaag &Antwoord sessie komt naar ons met dank aan SuperUser-een onderverdeling van Stack Exchange, een community-gestuurde groepering van Q & A-websites.
Foto met dank aan cobalt123( Flickr).
De vraag
SuperUser-lezer user1301428 wil weten hoe schijven worden geverifieerd nadat ze zijn gebrand:
Wat doet het verifiëren van schijf na het branden eigenlijk om de gegevens te verifiëren? Ik stel me voor dat het een soort vergelijking is tussen de originele bestanden en de bestanden die op de schijf zijn gebrand, maar weet iemand hoe het echt op een laag niveau wordt gedaan?
Ik bedoel, creëert het een hash van de bron- en doelinhoud en vergelijkt ze dan? Zo ja, slaat deze de hash van de gebrande inhoud op in de RAM?Of slaat het het op in een tijdelijk bestand op de harde schijf? Is er een logbestand van wat er aan de hand is?
Gewoon nieuwsgierig om precies te weten hoe deze functie werkt. En ik verwijs naar Windows Image Burner.
Hoe werkt het schijfverificatieproces?
Het antwoord
SuperUser-bijdragers Frank Thomas en Synetech hebben het antwoord voor ons. Ten eerste, Frank Thomas:
Bekijk deze MSDN-pagina's op Windows API voor de IBurnVerification-interface en de IMAPI_BURN_VERIFICATION_LEVEL-opsomming.
Voor gegevensschijven ziet het er in de snelle modus naar uit dat het niet de gehele schijf controleert, slechts een selectie van sectoren. Vervolgens zorgt het ervoor dat de API READ_DISC_INFO en READ_TRACK_INFO lukt tegen de nieuwe schijf.
Voor volledige verificatie voert het de bovenstaande controles uit en voert vervolgens een volledige controlesom uit op de laatste sessie op de nieuwe schijf tegen een controlesom berekend op de geheugenstroom die wordt gebrand. De controlesommen moeten in ram worden opgeslagen, maar het zijn waarschijnlijk kortstondige waarden. Merk op dat de vergelijking tegen het schijfbeeld in het RAM is, en niet tegen het bronmedium zelf, dus als de brongegevens niet correct hebben gelezen, zal deze verkeerd worden geschreven. Verificatie zal dit niet detecteren.
Voor muziekdiscs richt het zich op het controleren van READ_TRACK_INFO en de inhoudsopgave van de schijf, maar voert geen controlesomberekening uit. Er is geen volledige verificatiemodus voor muziek.
Gevolgd door het antwoord van Synetech:
Frank heeft de Windows-specifieke verificatie mooi uitgelegd. Ik zal een meer algemeen antwoord geven.
- Wat doet het controleren van de schijf na het branden eigenlijk om de gegevens te verifiëren?
- Ik bedoel, creëert het een hash van de bron- en doelinhoud en vergelijkt ze dan? Zo ja, slaat deze de hash van de gebrande inhoud op in de RAM?Of slaat het het op in een tijdelijk bestand op de harde schijf? Is er een logbestand van wat er aan de hand is?
Dat is zeker een manier om een vergelijking te implementeren: hash-één bestand( hopelijk met een voldoende grote lees-kans op botsingsalgoritmen), herhaal voor de ander en vergelijk hashes. Als dat is hoe een verificatie wordt geïmplementeerd, kunt u de drive-LED-flitser een tijdje zien knipperen en vervolgens knippert de CD / DVD-LED een tijdje.
Een andere manier om de verificatie te implementeren is door een blok van één bestand te lezen, dan hetzelfde blok uit het andere bestand, deze te vergelijken en dan te herhalen totdat het einde van het bestand is bereikt. In dit geval ziet u de leds van de twee schijven afwisselend heen en weer.
Natuurlijk, als de harde schijf en het optische station geen LED's hebben, zal het niet zo duidelijk zijn. Maar je kunt het nog steeds zien met iets als ProcessMonitor, omdat het een serie leesbewerkingen van de ene en vervolgens de andere in een enkele, grote burst of afwisselende, kleine bursts zal loggen.
- Ik stel me voor dat het een soort vergelijking is tussen de originele bestanden en de bestanden die op de schijf zijn gebrand, maar weet iemand hoe het echt op een laag niveau wordt gedaan?
Eigenlijk is het enige dat het doet het spoelen van de schijfcache zodat de vergelijkingsfunctie de gegevens van de werkelijke schijf leest in plaats van uit de geheugencache. Uiteraard is dit een kritieke stap, want als de verificatie gebeurt vanuit de cache, dan geeft dit niet aan wat er daadwerkelijk op de schijf staat, dus kan corruptie gemakkelijk doorschuiven.
U kunt zien of een vergelijking wordt gemaakt van het station of van de cache in het RAM-geheugen door hoe snel het gebeurt. Als u handmatig een eenvoudige vergelijking uitvoert( d.w.z. met WinDiff, WinMerge, of door ze te hashen met een hashing-tool), zult u merken dat de vergelijking veel sneller gaat dan verwacht omdat de bestanden uit de geheugencache worden gelezen. U moet de cache doorspoelen om deze van de werkelijke schijf te laten lezen. Voor optische stations( en andere verwijderbare media zoals flash-drives en geheugenkaarten) is het eenvoudig om de schijf uit te werpen om de cache te spoelen, maar voor harde schijven is het lang niet zo eenvoudig( hoewel dat meestal niet uitmaakt, omdat denieuw exemplaar is degene die u wilt testen).
Heeft u iets toe te voegen aan de uitleg? Geluid uit in de reacties. Wilt u meer antwoorden van andere technisch onderlegde Stack Exchange-gebruikers lezen? Bekijk de volledige discussiethread hier.
