The backstory is in my previous question and my own answer to it.
At one moment I had two partial images created by
ddrescue: one file on NTFS filesystem and the other on ext4.
I had noticed quite early in the process that the “size on disk” for both images was way lower than the total size, indicating (if I'm not mistaken) that those files had been written as “sparse”, i.e. that the empty data had not been actually allocated on the corresponding volumes, only the data which had already been rescued was accounted for. But at no point did I use the
-S switch in my
ddrescue commands, which specifies that the output file should be written as “sparse”.
Side note: What I did was using the
-R switch (“reverse”) at the beginning, figuring that it would allocate the whole size of the input HDD right away (the idea was that it would result in a “cleaner” output, writing all the data sequentially on the receiving partition, so as to preserve the integrity of the image file even if something would go wrong with the file system and I would have to recover the recovery…) ; it did indeed increase the displayed size of the file to 931.5GB, but in fact the “size on disk” was only increased by whatever small amount of data which was copied during that step.
So the main question would be: how can this sparseness be explained? Why is the
ddrescue copy not sequential by default?
Then, as I had two partial images, both containing some valid data missing from the other, I did the following:
- I attempted to copy the rescued areas from the second image on the ext4 partition, missing in the first image, to that first image on the NTFS partition, which should have been very fast, both images being on the same healthy 2TB HDD (a Seagate ST2000DX001 with a max write speed close to 200MB/s). But it turned out that it was very slow: only 660KB/s.
- So I stopped and did the opposite: I made
ddrescuecopy the rescued areas from the first image (on NTFS), missing in the second image, to that second image (on ext4). And now I got a copying rate of 43000KB/s or 43MB/s, which was considerably higher, and closer to a normal copying rate within the same HDD of that class and capacity.
The second question: could this weird behaviour be related to the performance issue which I experienced when writing to NTFS? Is the Linux NTFS driver known to have trouble dealing with large “sparse” files?