'Xác minh đĩa' thực sự làm gì sau khi ghi để xác minh dữ liệu?

Mục lục:

'Xác minh đĩa' thực sự làm gì sau khi ghi để xác minh dữ liệu?
'Xác minh đĩa' thực sự làm gì sau khi ghi để xác minh dữ liệu?

Video: 'Xác minh đĩa' thực sự làm gì sau khi ghi để xác minh dữ liệu?

Video: 'Xác minh đĩa' thực sự làm gì sau khi ghi để xác minh dữ liệu?
Video: TT 55 : phục hồi dữ liệu formar xóa nhằm trên USB BOX Ổ CỨNG - YouTube 2024, Tháng tư
Anonim
Tính năng ‘xác minh đĩa’ rất tuyệt vời để đảm bảo đĩa mới được đốt cháy của bạn trở nên tốt, nhưng chính xác nó hoạt động như thế nào? Bài đăng Hỏi & Đáp của SuperUser hôm nay có câu trả lời cho câu hỏi của người đọc tò mò.
Tính năng ‘xác minh đĩa’ rất tuyệt vời để đảm bảo đĩa mới được đốt cháy của bạn trở nên tốt, nhưng chính xác nó hoạt động như thế nào? Bài đăng Hỏi & Đáp của SuperUser hôm nay có câu trả lời cho câu hỏi của người đọc tò mò.

Phiên Hỏi & Đáp hôm nay đến với chúng tôi theo lịch sự của SuperUser - một phân khu của Stack Exchange, một nhóm các trang web Hỏi & Đáp do cộng đồng điều hành.

Ảnh lịch sự của cobalt123 (Flickr).

Câu hỏi

Người dùng SuperUser reader user1301428 muốn biết đĩa được xác minh như thế nào sau khi chúng được ghi:

What does verify disc after burning actually do to verify the data? I imagine it is some kind of comparison between the original files and the files that have been burned on the disc, but does anybody know how it is really done at a low level?

I mean, does it create a hash of the source and destination content, then compares them? If so, does it store the hash of the burned content in RAM? Or does it save it in a temporary file on the hard drive? Is there a log file of what is going on?

Just curious to know exactly how this feature works. And I am referring to Windows Image Burner.

Quy trình xác minh đĩa hoạt động như thế nào?

Câu trả lời

Những người đóng góp của SuperUser Frank Thomas và Synetech có câu trả lời cho chúng tôi. Đầu tiên, Frank Thomas:

Check out these MSDN pages on windows API for the IBurnVerification interface and the IMAPI_BURN_VERIFICATION_LEVEL enum.

For data discs, it looks like in quick mode it does not checksum the entire disc, just a selection of sectors. It then makes sure that the API calls READ_DISC_INFO and READ_TRACK_INFO succeed against the new disc.

For full verification, it performs the above checks, then does a full checksum on the last session on the new disc against a checksum computed on the memory stream being burned. The checksums have to be stored in ram, but they are likely short lived values. Note that the comparison is against the disc image in RAM, not the source media itself, so if the source data did not read correctly, it will be written incorrectly. Verification will not detect this.

For music discs, it focuses on checking READ_TRACK_INFO and the disc table of contents, but does not perform a checksum calculation. There is no full verification mode for music.

Tiếp theo là câu trả lời từ Synetech:

Frank nicely explained the Windows-specific verification. I will give a more general answer.

  • What does Verify disc after burning actually do to verify the data?
  • I mean, does it create a hash of the source and destination content, then compares them? If so, does it store the hash of the burned content in RAM? Or does it save it in a temporary file on the hard drive? Is there a log file of what is going on?

That is certainly one way a comparison can be implemented: hash one file (hopefully with a sufficiently large-read low chance of collision algorithm), repeat for the other, and compare hashes. If that is how a verification is implemented, then you will be able to see the drive-LED flash for a while, then the CD/DVD-LED flash for a while.

Another way to implement the verification is to read a block of one file, then the same block from the other file, compare them, then repeat until the end of the file is reached. In this case, you will see the LEDs of the two drives alternating back and forth.

Of course, if the the hard-drive and optical drive do not have LEDs, then it will not be as obvious. But you can still see it with something like ProcessMonitor because it will log a series of reads from one, then the other either in a single, big burst or alternating, small bursts.

I imagine it is some kind of comparison between the original files and the files that have been burned on the disc, but does anybody know how it is really done at a low level?

Actually, all it really does is to flush the drive cache so that the comparison function is reading the data from the actual disc instead of from the memory cache. Obviously this is a critical step because if the verification is done from cache, then it does not represent what is actually on the disc, so corruption can easily slip through.

You can see whether a comparison is done from the drive or from the cache in RAM by how fast it occurs. If you manually do a simple comparison (i.e. with WinDiff, WinMerge, or by hashing them with a hashing tool), you will notice that the comparison happens much faster than expected because it is reading the files from memory cache. You must flush the cache to force it to read from the actual disc. For optical drives (and other removable media like flash-drives and memory-cards), simply ejecting the drive is enough to flush the cache, but for hard-drives, it is not nearly as simple (though usually that does not matter because the new copy is the one you want to test).

Có cái gì để thêm vào lời giải thích? Tắt âm thanh trong các ý kiến. Bạn muốn đọc thêm câu trả lời từ những người dùng Stack Exchange có hiểu biết công nghệ khác? Xem toàn bộ chuỗi thảo luận tại đây.

Đề xuất: