partclone.ntfs attempting to copy sectors not associated with any file?

[Stevie-O]

I recently purchased a 4TB NVMe drive to replace my 2TB SATA drive from 2018, and was (technically, still am. it's slow-going) using Clonezilla to migrate my stuff.

I got about 30% of the way through and then the process aborted due to bad sectors.

I went back to Windows, ran a CHKDSK /R (which reads the contents of all files on disk to check for bad blocks) which lasted about 2 hours and reported no errors.

I then re-ran Clonezilla and it again failed at the same point.

After some googling, I found that with the -rescue option, I could look inside /var/log/clonezilla/partclone.log to see which blocks failed.

After figuring out that the numbers in the log file aren't sector numbers, they're byte offsets from the start of the partition, I found that there were 32 bad sectors, in 2 groups of 2 clusters each:

• 139509282-139509283
• 139509286-139509287

However, when I used ntfscluster to locate the files associated with these bad sectors -- so I would know which files needed to be repaired/recovered -- it reported no inodes found!

Even more interestingly:

• I found that clusters 139509281, 139509284-139509285, and 139509288 (the cluster before the first bad one, the two between, and the cluster after) contain a file.
• The same file, in fact.
• It's an audio file from a video game, which means it would have been written all in one go and shouldn't be fragmented.
• I used ntfscluster to locate the clusters containing that file, and a very interesting pattern emerged.

This file has seven fragments:

• 635 clusters starting at 139508647 (this ends on 139509281)
• one cluster at ...9439
• one cluster at ...9695
• 2 clusters at ...9284
• one cluster at ...9707
• one cluster at ...9944
• 151 clusters at ...9288

This file is effectively contiguous on disk except for four clusters. Remarkably, the four clusters that are out-of-order coincide with the four clusters that report read errors.

I was originally planning to wipe the old drive and use it as additional (albeit slower) storage space, but I'll leave it intact for now in case you want me to run any test commands.

[Stevie-O]

Update: After the copy finally finished, I successfully booted the machine and ran another CHKDSK.

It found one single error:

Found 0x1 clusters allocated to file "\Program Files (x86)\Steam\steamapps\common\Death's Door\DeathsDoor_Data\StreamingAssets\Audio\GeneratedSoundBanks\Windows\Pellegrino\562614104.wem <0x4c,0x1e339>" at offset "0x27b" marked as free
was not able to send command for self-healing due to lack of memory.

• This is the same file that lined up with the bad sectors
• 0x1e339 is 123705 decimal, which matches the "inode number" that the ntfscluster command reported
• 0x27b is 635 decimal, which corresponds to the first out-of-order cluster in the the file

[Thomas-Tsai]

Thank you for raising this issue. If CHKDSK is unable to repair the NTFS file system, it indicates a significant problem, potentially due to physical bad sectors or severe logical corruption.

I have two suggestion.

1. You can try adding the --force option to your partclone command. This will allow the cloning process to ignore read block errors and continue. However, any data in the corrupted sectors will be lost.

2. ddrescue is another choice for manual backup. It can normally back up all blocks. Running Partclone with the --domain option will create a domain/map file for ddrescue.

example for ddrescue and partclone:

partclone.ntfs -D -s  oldntfsdevice -o filesystem.map
ddrescue --domain-log filesystem.map oldntfsdevice  newntfsdevice rescue.log

[Stevie-O]

@Thomas-Tsai You seem to have misunderstood my report.

Here's the short version:

1. CHKDSK reported no errors when run against the filesystem on the original drive. CHKDSK /R -- which, to my understanding, rereads all occupied sectors, not just those limited to metadata -- also reported no errors.
2. partclone reported read errors on 4 clusters (32 sectors) when copying.
3. According to ntfscluster from the ntfs-3g suite, the four clusters that partclone failed to read were not allocated to any object.

I see two possibilities:

• The four clusters in question were in use by the filesystem. ntfscluster and CHKDSK were both wrong.
• The four clusters in question were not in use by the filesystem, ntfscluster and CHKDSK were correct. partclone was mistaken in believing those blocks/clusters were in use.

[Thomas-Tsai]

Partclone NTFS uses the ntfs_bit_get function in libntfs, which primarily uses bitmap information to determine whether a block needs to be backed up. Because the Partclone architecture only reads the bitmap table, there's no other way to determine whether a block is used.