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”
Samsung and from 2019 though:
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
Even months after, I really would like to thank you.
I have been lately migrating from LVM to BTRFS, and I encountered the same problem with the new installation. I have been able to fine-tune my config thanks to you without modifying my scheduler from none to bfq. This led to less freezing and less hiccups during my GNOME experience. I guess this is just my laptop’s fault, but I have been able to overcome this issue of mine.
I really wish more distros would set these vm.dirty_bytes and vm.dirty_background_bytes values out of the box.
By default, these values are percentage based on your ram, with dirty_background_ratio being 10% and dirty_ratio being 20%. The problem you had originally with the freezing is due to that, since those default values were made with 32-bit systems and 1gb of ram in mind, and need to be changed according to Linus Torvalds, but 10 years later they are still the same defaults.
The slowdowns get worse with the more ram you have, unless dirty_bytes and dirty_background_bytes are changed, which override dirty_ratio and dirty_background_ratio. I have to make this change on every Linux install with 64gb of ram to avoid 5+ minutes of complete freezing on large file transfers or downloads.
Hey there, I’m sorry for necroposting and I hope it’s okay, I have this problem and I’m still not sure how to solve it.
I have 40gb of RAM and I have major freezes, like ten minutes sometimes and it’s making my system unusable. This happens not just on Fedora, actually on every distro I tried.
I see that I’m supposed to change vm.dirty_background_bytes and vm.dirty_background_ratio in /etc/sysctl.d/99-sysctl.conf and I read a lot about this, but I still can’t quite understand how to know the values I should choose.
Could you please point me to some practical examples, or suggest me some reasonable values for 40gb? I’d really appreciate that, since I prefer to not mess with this kind of things.
It’s really odd seeing the same machine performing so much worse on 40gb compared to the previous 16 tho…
The quoted line seems to indicate that you may have added RAM, and going from 16G to 40G is an unusual value. It seems you added 24G and that would seem to indicate a mismatch in the sizes and possibly the speed of the new ram. Did you by chance add one 16G dimm and one 8G dimm? This seems like the only way to step up from 16g to 40g and probably would cause memory issues that may appear as other issues.
Please open a new thread for your specific issue and provide details of what changes were made before the problem was noted.