NTFS HDD slow operations (moving, copying)

I have one internal HDD 1TB WD wd1003fzex. I was using that drive as my partition “D” while I was on Windows. It is NTFS.
I also have an SSD on which Fedora is installed.

The speed while I was copying or moving files on Windows was ok, around the advertised ones.

However, when I installed Fedora, speeds were really slow on that NTFS HDD, like 20MB/s while moving/copying files:
sc

fstab:

UUID=XXXXX                       /mnt/files   ntfs    defaults                       0 0

Same problem when I press “Delete” (moving to the trashbin), or moving files within the same HDD.

Any solution to this?

I doubt there is anything in the code that would make much of a difference performance wise. The limiting factor is likely the drive itself (unless you are adding encryption, which does have some overhead).

If there are significant performance differences, it is likely that Windows was taking some “shortcuts”. Changing default to async,big_writes might yield results more in-line with what Windows was doing.

noatime is another performance-improving option that you might try adding to the list.

There are trade-offs. You should read up on the options to understand what they do.

1 Like

That helped a bit, the speed is now around 50-80 MB/s.

Any other suggestions?

Speed test KDiskMark, 5 passes, 1GiB:
Screenshot_20240804_201857
Not sure if these results are ok, but copying/moving files using Dolphin is still pretty slow IMO.

Assuming this is a rotational disk, you can try changing the “AAM” level.

Excerpted from man hdparm:

       -M     Get/set Automatic Acoustic Management (AAM) setting. Most modern harddisk dri‐
              ves  have  the  ability to speed down the head movements to reduce their noise
              output.  The possible values are between 0 and 254. 128 is the most quiet (and
              therefore slowest) setting and 254 the fastest (and loudest). Some drives have
              only two levels (quiet / fast), while others may have different levels between
              128 and 254.  At the moment, most drives only support 3 options,  off,  quiet,
              and fast.  These have been assigned the values 0, 128, and 254 at present, re‐
              spectively,  but  integer  space  has  been incorporated for future expansion,
              should this change.

I like to change that to 254 on some of my old servers:

# for i in sd{a..j}; do echo -n "$i: "; hdparm -M /dev/$i | grep acoustic; done
sda:  acoustic      = 254 (128=quiet ... 254=fast)
sdb:  acoustic      = 254 (128=quiet ... 254=fast)
sdc:  acoustic      = 254 (128=quiet ... 254=fast)
sdd:  acoustic      = 254 (128=quiet ... 254=fast)
sde:  acoustic      = 254 (128=quiet ... 254=fast)
sdf:  acoustic      = 254 (128=quiet ... 254=fast)
sdg:  acoustic      = 254 (128=quiet ... 254=fast)
sdh:  acoustic      = 254 (128=quiet ... 254=fast)
sdi:  acoustic      = 254 (128=quiet ... 254=fast)
sdj:  acoustic      = 254 (128=quiet ... 254=fast)

Other than that, maybe make sure your cables are good. In the old IDE days, the quality of the ribbon cable could make a world of difference. I’m not sure if there is that much of a difference in their ratings these days, but a bad cable could still be a cause of performance degradation.

Oh, actually, for rotational disks, file fragmentation can be one of the biggest issues with read/write performance. I’m not sure if there is a way to defrag NTFS from Linux, but that might be worthwhile doing if you can figure out how. (One way to defragment a filesystem is to create another filesystem and do a straight copy of all the files from the old filesystem to the new one.)

Partition alignment is another thing to check: Misalignment can be Twice the Cost That is an unlikely problem because modern partitioning tools a pretty good about making sure that doesn’t happen. But if you used an old tool to do the partitioning or if you are doing something exotic with regard to how you access your storage, it might be an issue.

Edit: I looked up your drive’s specs and 150MB/s is what it is rated for. So if you are getting that, then there is nothing wrong with the hardware or the cable. File fragmentation and partition alignment are the only things that could be causing the slowdown. I would consider reformatting the drive with XFS.

2 Likes

Since I need that drive to be accessible from Windows too (dual boot), would XFS be a problem? If so, which other partition technique would you suggest?

Thank you for the detailed answer.

As far as I know, Windows is not able to access XFS. So if you need to access the drive from both Windows and Linux, XFS would not be a good choice for you. I think the NTFS driver in Linux uses a technology called FUSE that runs in userspace. There might be a little system call overhead that comes with using a FUSE-based filesystem that wouldn’t exist for drivers that run in kernel space. The exFAT filesystem driver runs directly in kernel space, so it might perform a little better than the NTFS implementation: Which Fedora-kernel will first have in-kernel exfat support enabled?

2 Likes