My laptop with an NVME happily runs Fedora workstation. However, when I’m copying a huge quantity of data from an external hard drive to the NVME I experience freezes alternating to a normally responsive system. After I launch a copy of a big quantity (some GBs), this occurs in order:
copy starts at full speed for ~10s
copy freezes for around 10 to 15s.
meanwhile, the system freezes, I cannot open the terminal, nor type commands, nor interact with windows or applications
after some seconds, the freeze goes away and the system responds as usual. The copy keeps going on at full speed
go to 1, until everything has been successfully copied.
This might not be a problem if I leave my computer alone when I’m copying huge files, but when I’m using the computer it prevents me to do basic things like switching applications and opening a terminal.
What can I do in order to prevent this? Is this solvable, or is it my nvme’s fault?
It seems likely that either something is using a lot of cpu time or the system is using a lot of memory and has to free up RAM so the buffering can resume. My guess would be either a smaller amount of RAM than required or something using a lot of RAM. The buffer seems to need to fill then empty before it can fill again.
Almost every process that involves large quantities of data data being transferred uses RAM buffering to smooth out the intermittent reads and writes on devices. The transfer always starts fast until the buffer fills then smooths out to the actual write speed. The fact that it slows other actions on the system may be swap, inadequate ram, or processes filling the ram that is needed for normal operation.
It very seldom would seem related to an nvme unless you have both ends as nvme then it would seem the data link between as the data transfer restriction but that still should not interfere with other system operations as you describe on the desktop.
How much ram do you actually have installed?
Would you please provide the output of inxi -Fzxx so we can see the hardware config involved.
Also the output of free while doing a large transfer with this symptom occurring
What filesystem? Use smartmontools to check that the nvme isn’t failing or overheating. There may be relevant messages in journalctl or dmesg. If these don’t provides hints to the source of the problem, try running a “top” utility (bpytop is a good example).
The use of luks, which does require a bit more processing by the kernel during transfers.
I do not suspect this as a major part since only 4 of the 8 cpus show more than a very low speed and even they are showing only slightly over 50% of full speed.
The use of raid on the device, using the built-in bios raid.
I am unsure of this, but would consider it as potentially a major factor with disk IO. Raid is known to have an affect on write speeds, and since it is bios/intel/hardware raid and not a linux raid the OS has little control over what it does beyond the driver to enable it. With a single disk and no established raid0 or raid1 parameters it seems totally useless.
list all devices: sudo sst show -ssd
Data Integrity: sudo sst start -ssd 1 -scan [(DataIntegrity|ReadScan|Logs)]
smart selftest: sudo sst start -ssd 1 -selftest [short|extended]
smart selftest done: sudo sst show -ssd 1 -selftest
smart Werte: sudo sst show -ssd 1 -smart
health/hours: sudo sst show -ssd 1 -sensor
LBA written: sudo sst show -ssd 1 -performance
Wearout Indicator: sudo sst show -ssd 1 -smart E9
Device Idenify: sudo sst show -ssd 1 -identify
Drive Info/Feature: sudo sst show -ssd 1 -a
Note:
I use index=1 here in the above commands (… -ssd 1).
the correct index comes from the first command (list all…) !
I would also check the external drive with smartmontools (maybe via Gnome disk) an/or e2fsck (if ext)
you could run “sudo journalctl -f” in another terminal during copying to see what’s going on.
sudo fstrim -va might help too
I would also try to find out if the NVme degrades write speed when the disk is filled.
I always use ~10% Over-Provisioning on my ssd’s (don’t know if this is currently necessary at all this days) and from time to time a “secure erase”
I guess you would be better off with brtfs and it’s compression to conserve the NVMe.
and of cause for the upcoming F38’s “RPM Copy on Write”: https://fedoraproject.org/wiki/Changes/RPMCoW
What do you call ‘large file’ … NVME is specific hardware memory being non-volatile so fast as things just stay if not changed not needing to be reloaded. Ext4 is a journal file system needing writing backup data. Try SSD, probably faster for what you are doing, try XFS file system that doesn’t journal or JFS. BTRFS has random ENOSPC data loss so might not fit for you …
Following advice from the official Telegram group, I was asked to switch to bfq scheduler for the NVMe to assure a fairer use of IO resources during high copy workloads. This helped a lot, although sometimes it still freezes if performing multiple copy tasks together. To switch to bfq I created the following file with content