Hvad gør 'Verify Disc' faktisk efter Burning for at verificere dataene?

Funktionen 'Kontroller disk' er fantastisk til at sikre, at din friskbrændte disk viste sig godt, men hvordan virker det præcist? Dagens SuperUser Q & A-indlæg har svaret på en nysgerrig læsers spørgsmål.

Dagens Spørgsmål & Svar session kommer til os med venlig hilsen af ​​SuperUser-en underafdeling af Stack Exchange, en community-driven gruppe af Q & A-websteder.

Foto med tilladelse til cobalt123 (Flickr).

Spørgsmålet

SuperUser læser user1301428 ønsker at vide, hvordan diske er verificeret efter at de er brændt:

Hvad kontrollerer disken efter brænding faktisk at verificere dataene? Jeg forestiller mig, at det er en slags sammenligning mellem de oprindelige filer og de filer, der er blevet brændt på disken, men ved nogen, hvordan det virkelig gøres på et lavt niveau?

Mener jeg, skaber det en hash af kilden og destinationsindholdet, og sammenligner dem derefter? Hvis ja, gemmer den hash for det brændte indhold i RAM? Eller gemmer den det i en midlertidig fil på harddisken? Er der en logfil af, hvad der sker?

Bare nysgerrig efter at vide præcis, hvordan denne funktion virker. Og jeg henviser til Windows Image Burner.

Hvordan virker diskverifikationsprocessen?

Svaret

SuperUser bidragsydere Frank Thomas og Synetech har svaret for os. Først op, Frank Thomas:

Tjek disse MSDN-sider på Windows API til IBurnVerification-grænsefladen og IMAPI_BURN_VERIFICATION_LEVEL enummen.

For datadiske ser det ud i hurtig tilstand, det kontrollerer ikke hele disken, kun et udvalg af sektorer. Det sørger derefter for, at API'en kalder READ_DISC_INFO og READ_TRACK_INFO lykkes mod den nye disk.

For fuld verifikation udfører den ovennævnte kontrol, så udføres en fuld checksum for den sidste session på den nye disk mod et checksum beregnet på hukommelsesstrømmen, der brændes. Kontrolsummerne skal opbevares i ram, men de er sandsynligvis kortvarige værdier. Bemærk, at sammenligningen er imod diskbilledet i RAM, ikke selve kildemediet, så hvis kildedataene ikke blev læst korrekt, vil det blive skrevet forkert. Verifikationen vil ikke registrere dette.

For musik diske fokuserer den på at kontrollere READ_TRACK_INFO og diskens indholdsfortegnelse, men udfører ikke en checksumberegning. Der er ingen fuld verifikationsfunktion til musik.

Efterfulgt af svaret fra Synetech:

Frank forklarede pænt den Windows-specifikke verifikation. Jeg vil give et mere generelt svar.

• Hvad gør Verify Disc efter brænding faktisk gøre for at verificere dataene?
• Mener jeg, skaber det en hash af kilden og destinationsindholdet, og sammenligner dem derefter? Hvis ja, gemmer den hash for det brændte indhold i RAM? Eller gemmer den det i en midlertidig fil på harddisken? Er der en logfil af, hvad der sker?

Det er bestemt en måde, en sammenligning kan implementeres: hash en fil (forhåbentlig med en tilstrækkelig storlæsning lav chance for kollisionsalgoritme), gentag den anden og sammenlign hash. Hvis det er sådan, hvordan en verifikation gennemføres, så vil du kunne se drev-LED-blitz et stykke tid, så blinker CD / DVD-LED'en et stykke tid.

En anden måde at gennemføre verifikationen på er at læse en blok af en fil, så den samme blok fra den anden fil, sammenligne dem, og gentag indtil slutningen af ​​filen er nået. I dette tilfælde vil du se LED'erne på de to drev skiftevis frem og tilbage.

Selvfølgelig, hvis harddisken og det optiske drev ikke har lysdioder, så bliver det ikke så klart. Men du kan stadig se det med noget som ProcessMonitor, fordi det logger en serie af læsninger fra en, så den anden enten i en enkelt, stor burst eller vekslende, små udbrud.

• Jeg forestiller mig, at det er en slags sammenligning mellem de oprindelige filer og de filer, der er blevet brændt på disken, men ved nogen, hvordan det virkelig gøres på et lavt niveau?

Faktisk er alt det, der virkelig er, at skylle drevcache, så sammenligningsfunktionen læser dataene fra den aktuelle disk i stedet for fra hukommelsescachen. Det er klart, at dette er et kritisk trin, fordi hvis verifikationen er udført i cachen, repræsenterer det ikke, hvad der faktisk er på disken, så korruption kan let glide igennem.

Du kan se, om en sammenligning sker fra drevet eller fra cachen i RAM ved, hvor hurtigt det sker. Hvis du manuelt foretager en simpel sammenligning (dvs. med WinDiff, WinMerge eller ved hashing dem med et hashing-værktøj), vil du bemærke, at sammenligningen sker meget hurtigere end forventet, fordi det læser filerne fra hukommelsescache. Du skal skylle cachen for at tvinge den til at læse fra den aktuelle disk. For optiske drev (og andre flytbare medier som flashdrev og hukommelseskort) er det simpelthen, at udstødning af drevet er tilstrækkeligt til at skylle cachen, men for harddiske er det næsten ikke så simpelt (selvom det normalt ikke betyder noget, fordi ny kopi er den du vil teste).

Har du noget at tilføje til forklaringen? Lyde af i kommentarerne. Vil du læse flere svar fra andre tech-savvy Stack Exchange brugere? Tjek den fulde diskussionstråd her.