0

Writing large files to my primary SSD seems to be slow and I'm trying to find the reason. Mainboard is a ASUS Maximus VIII Hero and I've got two SSDs connected:

  1. Samsung SSD 840 EVO 120GB --> sda
  2. Samsung SSD 840 EVO 500 GB --> sdb

Here's the fdisk -l output

Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A3DB9022-5AE0-4BF4-BCA0-E0DAF7BB2106

Device         Start       End   Sectors  Size Type
/dev/sda1       2048   1050623   1048576  512M EFI System
/dev/sda2    1050624 167569407 166518784 79.4G Linux filesystem
/dev/sda3  167569408 234440703  66871296 31.9G Linux swap

Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

So the 120GB is my system disk and the 500GB is a secondary disk. If I write to the SSDs with dd, I get the following results:

sda:

~$ dd if=/dev/zero of=/tmp/dd_performance bs=1G count=1 oflag=direct
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.1183 s, 507 MB/s

~$ dd if=/dev/zero of=/tmp/dd_performance bs=1G count=10 oflag=direct
10737418240 bytes (11 GB, 10 GiB) copied, 296.29 s, 36.2 MB/s

sdb:

~$ dd if=/dev/zero of=/mnt/temp_data/dd_performance bs=1G count=1 oflag=direct
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 2.13052 s, 504 MB/s

~$ dd if=/dev/zero of=/mnt/temp_data/dd_performance bs=1G count=10 oflag=direct
10737418240 bytes (11 GB, 10 GiB) copied, 21.1424 s, 508 MB/s

So for a 1GB file, I get very similar results. But writing a 10GB file to sda gets painfully slow.

I found similar questions but thought that the oflag=direct should skip all caches and write directly. During the execution, I had 25GB of free memory.

The only explanation I've come up with is that sda has much more files (system disk) and the SSD probably has more work to do to fit a 10GB file on it than on sdb. Is this behavior normal? Is there a better test I could execute?

  • I believe your incorrect use of dd’s bs parameter is affecting performance negatively. Also, benchmarks show that the 840 EVO has nowhere near that write performance, further hinting at flawed testing. // Apart from all that: The 500 GB model has twice the “TurboWrite” cache, 6 GB. – Daniel B Oct 1 '17 at 12:10
  • Can you explain what I'm doing wrong with the bs parameter? The TurboWrite cache hint is interesting, thanks! Since both are 840 EVO I didn't see any differences myself. – pgruetter Oct 1 '17 at 12:13
  • 1
    There’s an optimal block size for any transfer. It’s usually somewhere around 256K-1M. It will be different depending on what’s on either end of the transfer. Check this answer on that specific topic. – Daniel B Oct 1 '17 at 12:31
  • Tried the test again with bs=1M count=10000 and got 122MB/s. Will probably try other tools as well. – pgruetter Oct 1 '17 at 15:40
  • 1
0

Thanks to Daniel Bs comment, I'm certain the the behavior is normal.

Solution

The two disks have vastly different TurboWrites and a drop is expected when writing large files. For the smaller disk, the drop just happens sooner and is much larger. Also, the blocksize (1G) I used is not optimal for tests. Using a more reasonable 1M gives better results.

Conclusion

I will still use the smaller disk for my system paritions as they have many small files and these work fast. But I will move two VMs I'm also running on this SSD to the larger one as I frequently do backups and copy these around.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.