How is this possible? Very slow file speed transfer on NVME SSD

What did I do wrong here, maybe someone can give me some ideas where to start.
I just tried to copy some movies from one folder to another on the same partition, I have 16Gb of ram and half of it its free, ssd temp is bellow 50, what the hell is with this speed?
to hell, this is a XPG GAMMIX S11 Pro PCIe Gen3x4 M.2 2280 Solid State Drive
sdfsdfsdfsdfsdfsdfsdf

In your case, use “link”, not “copy”. It’s almost instant.

In terms of slow write speed, there’re tons of reasons for that, for example, bad blocks on the drive, bad params in config, need to trim, system heavy load on I/O, etc. You need to check the system to figure out the root cause.

2 Likes

I didn’t need to copy those file, was just playing around, wanted to test…the drive is almost new, no bad blocks, I trimmed it just now and tried again, first 2gigs are almost instant(probably the buffer) then it drops down to 20Mb/s.
I tried copying from another ssd to this one, first 7-8gigs went at about 500Mb/s, then it dropped down to around 100Mb/s and stay there for the rest of the operation but my mouse cursor was stuttering when moving it. feck :unamused:

In Linux, disk I/O doesn’t happen immediately. Data is first buffered/cached in your RAM, them a kernel thread (maybe more depends on your config) is responsible to flush data to the physical disk. Even after the actual write is completed, the buffered/cached data stays in your RAM in case you need to access it. This design is for best system performance. Now you understand why the first xGBs are always faster. RAM access is way faster than disk I/O. So quickly, your RAM will be filled up and the system needs to sync and recollect more space. System now is under heavy load on I/O. You can tweak your system to change the behavior, for example, ram used for cache/buffer, number of kernel threads to work on disk flush, how often system syncs, or if you like, bypass the cache/buffer mechanism and make every write operation synchronized.

1 Like

I understand everything that you are saying but I’m just thinking that it’s not normal to get so low speeds on a new drive of this type when the rest of the system its idle.
So I get 50+Mb/s downloading from the internet but I can only copy a large file on the same partition with only 20Mb/s? Right now it makes no sense in my head, I’ll need to dig a bit see what’s happening.

Use cp -v or mv -v or rsync they should be a lot faster if it’s on the same partition all they need to do is call the rename(2) syscall which just changes the underlying filesystem linking inodes (fast). My fork of noice does just this for copy/move.

I suspect whatever program you’re using is doing a full copy and slowly, where they use a buffer of bytes and read/write from the old to the new. Increased buffer size can help speed things up but not for small files.

This is very true but also very dependent on many things, mostly just how the program is written, many will call fflush(2) after an operation to force a flush to disk. On large transfers like this it should be buffered to avoid slowdowns and flush at the end but I can’t say for sure. It’s also quite rare that your ram is consumed by a copy operation unless the program decides to load the whole file into ram, most will read a small chunk at a time.

1 Like

fflush() dumps data from the stream’s buffer to kernel buffer/cache only. Even sync()/fsycn() is called, the kernel doesn’t drop the caches. It needs those blocks stay in the RB tree for potential reads in the near future.

1 Like

Yea you’re absolutely right, the kernel is free to wait and only sync when it wants/needs.

Moving files or folders is instant. Doing a full copy is way too slow. Again, I don’t need to do this, was just playing around and thought that this weird, even copying files from this partition to a usb stick I get 30-40Mb/s constantly but not for copying files on the same partition.
cp has the same speed, rsync is even slower: