My dual-boot Ubuntu 18.04 and Windows laptop has begun displaying some unusual behaviour. I have a boot SSD, which is formatted with an ext4 partition and an NTFS partition, and a data hard drive which is entirely NTFS.

The performance of the SSD is fine on both partitions. However, the performance of the hard drive has suddenly nosedived, and is behaving very unusually.

It is taking around five seconds to perform ls or load Nautilus at the root of the hard drive, though if something else is using the drive heavily (such as Steam) I've seen it take as long as one minute, or even hang indefinitely until a restart. Steam also crashes or hangs for long periods of time while downloading games or updates to the drive. At worst, I've had nothing able to access the disk at all, ls hanging indefinitely, and even GNOME Disks crashing when selecting the disk from the side bar.

Crucially, the performance on Windows is absolutely fine. Explorer listings for the drive load almost instantly, as does the dir command. Whatever is happening here must be an issue with my Linux installation.

At one stage, the drive locked up completely and Steam said that there was corrupt data on the disk. I rebooted into Windows and that said the same thing. I ran chkdsk /f E: on the hard drive (where E: is the hard drive's letter in Windows). This found many errors, fixed the corruption, and made a minor performance improvement, but it is still unusually slow.

SMART says that the drive's health is fine, and a GNOME Disks self-test flags no errors.

My /etc/fstab is:

# /etc/fstab: static file system information.
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/nvme0n1p7 during installation
UUID=24348190-099b-4029-a8bd-13e1f91e396c /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=D816-4C34  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0
/dev/disk/by-uuid/3A8294518294138B /mnt/3A8294518294138B auto nosuid,nodev,nofail,x-gvfs-show,defaults,exec,uid=1000,gid=1000 0 0

...where the last line defines the hard drive. (The Windows SSD partition isn't here; I mount that into /media/aaron through Nautilus if I need it.)

How can I diagnose what might be causing this?

  • NTFS isn't the problem if the NTFS partition in the SSD works fine.
    – user880592
    Jul 9, 2019 at 22:11

1 Answer 1


Does this happen with other hard drives and flash drives, or just the one? For me, all external media (hard drives, flash drives) caused slowdown on Ubuntu 18.04 but worked fine on Windows 10. This persisted on two machines, across three filesystems (UDF, NTFS, and exFat).

I found two pages that were instrumental in fixing this: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1208993 https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/

The solution:

I added these two lines to /etc/sysctl.conf:

vm.dirty_background_ratio = 10
vm.dirty_ratio = 20

and ran sudo sysctl -p. This solution is proposed here as well. It seems to be an issue impacting 64-bit Linux machines with a lot of RAM. If you try this, please let me know if this does (or does not) work for you, in case this is a new issue!

  • 1
    This seems to have made an improvement! I do indeed have a fair bit of RAM (16GB). Thanks a bunch! Jul 17, 2019 at 19:44
  • 1
    The link implies that this is just for virtual machines. Is that the case? Jul 17, 2019 at 20:07
  • 2
    @OrganicMarble That's what I thought, but it worked like a charm for me despite not being on a VM.
    – lynn
    Jul 17, 2019 at 20:13
  • Thanks! Will give it a spin. Jul 17, 2019 at 20:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .