Slow SSD R/W speeds on NTFS partition with Linux Mint.

[HackerCop]

Hello, I'm running both Linux Mint and Windows 10 and I have a Ext4 partition for Linux Mint and an NTFS partition for windows. When reading and writing (copying and pasting) files on the NTFS partition with linux mint I can't get faster than 50MB/s yet when I benchmarked it using the disks utility I got R/W speeds in excess of 680MB/s. There is no problem with the Ext4 partition and windows works fine with the NTFS partition. If someone could help me fix this I would be very grateful. Here's the result of inxi -Fxxxrz

Code: Select all

System:
  Kernel: 5.4.0-70-generic x86_64 bits: 64 compiler: gcc v: 9.3.0 
  Desktop: Cinnamon 4.8.6 wm: muffin 4.8.1 dm: LightDM 1.30.0 
  Distro: Linux Mint 20.1 Ulyssa base: Ubuntu 20.04 focal 
Machine:
  Type: Laptop System: Dell product: Inspiron 3482 v: 1.7.1 serial: <filter> 
  Chassis: type: 10 serial: <filter> 
  Mobo: Dell model: 0DYPY5 v: A01 serial: <filter> UEFI: Dell v: 1.7.1 
  date: 07/22/2020 
Battery:
  ID-1: BAT1 charge: 17.9 Wh condition: 33.6/42.0 Wh (80%) volts: 12.4/11.4 
  model: COMPAL PABAS0241231 type: Li-ion serial: <filter> status: Charging 
CPU:
  Topology: Quad Core model: Intel Pentium Silver N5000 bits: 64 type: MCP 
  arch: Goldmont Plus rev: 1 L2 cache: 4096 KiB 
  flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 8755 
  Speed: 2153 MHz min/max: 800/2700 MHz Core speeds (MHz): 1: 2153 2: 2009 
  3: 2175 4: 2158 
Graphics:
  Device-1: Intel UHD Graphics 605 vendor: Dell driver: i915 v: kernel 
  bus ID: 00:02.0 chip ID: 8086:3184 
  Display: x11 server: X.Org 1.20.9 driver: modesetting unloaded: fbdev,vesa 
  resolution: 1920x1080~60Hz 
  OpenGL: renderer: Mesa Intel UHD Graphics 605 (GLK 3) v: 4.6 Mesa 20.2.6 
  direct render: Yes 
Audio:
  Device-1: Intel vendor: Dell driver: snd_hda_intel v: kernel 
  bus ID: 00:0e.0 chip ID: 8086:3198 
  Sound Server: ALSA v: k5.4.0-70-generic 
Network:
  Device-1: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter 
  vendor: Dell driver: ath10k_pci v: kernel port: f040 bus ID: 02:00.0 
  chip ID: 168c:0042 
  IF: wlp2s0 state: up mac: <filter> 
  Device-2: Qualcomm Atheros type: USB driver: btusb bus ID: 1-4:2 
  chip ID: 0cf3:e009 
Drives:
  Local Storage: total: 238.47 GiB used: 173.67 GiB (72.8%) 
  ID-1: /dev/nvme0n1 model: PC SN520 NVMe WDC 256GB size: 238.47 GiB 
  speed: 15.8 Gb/s lanes: 2 serial: <filter> rev: 20240012 scheme: GPT 
Partition:
  ID-1: / size: 24.79 GiB used: 16.71 GiB (67.4%) fs: ext4 
  dev: /dev/nvme0n1p7 
Sensors:
  System Temperatures: cpu: 60.0 C mobo: N/A sodimm: 43.0 C 
  Fan Speeds (RPM): N/A 
Repos:
  No active apt repos in: /etc/apt/sources.list 
  Active apt repos in: /etc/apt/sources.list.d/brave-browser-release.list 
  1: deb [arch=amd64] https://brave-browser-apt-release.s3.brave.com/ stable main
  Active apt repos in: /etc/apt/sources.list.d/official-package-repositories.list 
  1: deb http://packages.linuxmint.com ulyssa main upstream import backport #id:linuxmint_main
  2: deb http://archive.ubuntu.com/ubuntu focal main restricted universe multiverse
  3: deb http://archive.ubuntu.com/ubuntu focal-updates main restricted universe multiverse
  4: deb http://archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse
  5: deb http://security.ubuntu.com/ubuntu/ focal-security main restricted universe multiverse
  6: deb http://archive.canonical.com/ubuntu/ focal partner
  Active apt repos in: /etc/apt/sources.list.d/spotify.list 
  1: deb http://repository.spotify.com stable non-free
  Active apt repos in: /etc/apt/sources.list.d/vscode.list 
  1: deb [arch=amd64,arm64,armhf] http://packages.microsoft.com/repos/code stable main
Info:
  Processes: 224 Uptime: 1d 6h 14m Memory: 7.59 GiB used: 1.86 GiB (24.5%) 
  Init: systemd v: 245 runlevel: 5 Compilers: gcc: 9.3.0 alt: 9 Shell: bash 
  v: 5.0.17 running in: gnome-terminal inxi: 3.0.38 

[rene]

You'd ideally first test from the command line, with e.g.

Code: Select all

rsync -v /big/source/directory /existing/destination/on/ntfs/

This of course implies that the NTFS destination partition needs to be mounted. If you do that from a file-manager, it's mounted under /media/<username>; see the output of mount or df or some such to see where it's at.

The reason is near-chronically broken state of graphical file managers. If the rsync works at full-ish speed you'll need to investigate at that level rather than "Linux" as such.

[HackerCop]

Thanks for your reply, I tried what you suggested but I got this

Code: Select all

$ rsync -v RMCP01.iso "/mnt/6458BBB058BB7EFC/Users/15poo/Documents/MKW ISO/copy"
RMCP01.iso

sent 4,701,127,308 bytes  received 35 bytes  35,214,437.03 bytes/sec
total size is 4,699,979,776  speedup is 1.00

That's saying that I only achieved 35MB/s which is awful but we now know that the problems not caused by the GUI file manager. Note that when I copy from NTFS to Ext4 I can get full speeds its just NTFS to NTFS thats the problem. Do you have any other ideas. Thanks.

[rene]

May I assume that the source in that 35M/s copy was not also on /mnt/6458BBB058BB7EFC/? (you are not showing current directory).

If it was and if I had noticed this locally I'd have in fact probably shrugged this off, what with NTFS on Linux being a FUSE filesystem, a filesystem implemented in user- rather than kernelspace and with hence horrible syscall round-trip times. Or, well, no, but I would have had this been a large directory of individual small files instead of an ISO: 35 M/s does sound atrocious for one ISO.

I was just testing a bit locally and while I get poor write performance on NTFS it's more than double yours and for me ext4 -> NTFS is actually slightly slower than NTFS -> NTFS. I can only test on an older system with one NTFS filesystem on a two drive SATA SSD RAID0 and the other on a two drive HDD raid 0 due to not having NTFS filesystems anywhere else. Comparisons as such therefore not likely too relevant but I thought I might notice similar patterns at least.

As said, surely do notice a pattern of NTFS being slow but "unfortunately" nothing near your 35 vs 680, and as said, certainly not specific to NTFS -> NTFS. Shall have to excuse myself from the thread therefore; do not know; sorry.

[altair4]

You might consider adding another option to your ntfs mount expression in fstab: big_writes

big_writes
This option prevents fuse from splitting write buffers into 4K chunks, enabling big write buffers to be transferred
from the application in a single step (up to some system limit, generally 128K bytes).

It's the default in libfuse3 but Mint is using libfuse2.

[HackerCop]

Could you show me how to do that (adding big_writes to fstab) is there a terminal command? Also I'm taking from your reply that mint does not use libfuse2 I did some research and I found that ubuntu does use libfuse3 I've been having a few issues like this with mint and I'm wondering if ubuntu's a better option for me. I found that when I tried it that there were less problems like this but I disliked the UI hence why I'm using mint.

[altair4]

The version of Ubuntu that Mint is based on uses libfuse2 so ....

Your posted mount point is /mnt/6458BBB058BB7EFC so there must be an entry in /etc/fstab for that mount point. Why not post the output of the following:

Code: Select all

cat /etc/fstab

[HackerCop]

Here you go:

Code: Select all

$ cat /etc/fstab
# /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=a98c135d-8ad1-4eaa-be44-3686723c42ce /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=FCB7-B563  /boot/efi       vfat    umask=0077      0       1
/swapfile                                 none            swap    sw              0       0
/dev/disk/by-uuid/6458BBB058BB7EFC /mnt/6458BBB058BB7EFC auto nosuid,nodev,nofail,x-gvfs-show 0 0

[altair4]

/dev/disk/by-uuid/6458BBB058BB7EFC /mnt/6458BBB058BB7EFC auto nosuid,nodev,nofail,x-gvfs-show 0 0

That line in fstab must have been created by the Disks utility. I don't use it so I don't know if you can edit those options from within it but one way or another you need to change that line so that it looks like this:

/dev/disk/by-uuid/6458BBB058BB7EFC /mnt/6458BBB058BB7EFC auto nosuid,nodev,nofail,x-gvfs-show,big_writes 0 0

If you are editing /etc/fstab directly the procedure would be to:

[1] Unmount the partition:

Code: Select all

sudo umount /mnt/6458BBB058BB7EFC

[2] Edit /etc/fstab and make the change.

[3] Then remount with this command:

Code: Select all

sudo mount -a

Maybe Disks does all that for you --- I have no idea.

[HackerCop]

Its been a while since I last responded and I'm now a programmer and a much more advanced user and I'm now using Fedora 34 instead of linux mint after distro hopping but I had the same problem with that so I tried this and it worked. Thank you very much sir.