I often do data recovery jobs using ddrescue or similar programs. The disk image is written sparsely, because often only parts of the disk is being imaged (using ddrescue domain files and the like). However, on a heavily damaged disk, ddrescue will skip hundreds of times, leading to a file with many fragments.

Until now I've been using an NTFS filesystem for storing the images, but I find that after heavy fragmentation the writes get bogged down (I believe NTFS rewrites the entire fragment metadata every time a new fragment is added).

Among the Linux filesystems is there one more optimized for fragmentation?

  • 1
    Why not recovering to raw partitions and letting ddrescue writing the control files in the local directory? – Rui F Ribeiro May 22 at 20:40
  • @RuiFRibeiro Often I want a sparse file - if the disk is not too damaged, and I'm only recovering certain parts of the filesystem. I won't know about the damage until much of the way through the recovery, and then my only solution is to 'inflate' the file by copying it with dd. – afuna May 22 at 20:41
  • I've since discovered that I can use ntfsfallocate from the ntfsutils collection to inflate the file in place. However, a better filesystem is still preferred. – afuna May 25 at 20:51
  • While not an fs recommendation; can't you use dd to truncate the "empty" blocks? Rather than pad them all in an equal, chosen block length? Wouldn't that eliminate the "slack"? – somebody Jun 15 at 6:37
  • @somebody Do you mean to writes 0's to the file 'holes' - that's the equivalent of inflating the file using ntfsallocate. Did I misunderstand you? – afuna Jun 15 at 20:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.