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:
- Samsung SSD 840 EVO 120GB --> sda
- 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
’sbs
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 – 2017-10-01T12:10:12.830Can 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 – 2017-10-01T12:13:02.673
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 – 2017-10-01T12:31:47.373Tried the test again with bs=1M count=10000 and got 122MB/s. Will probably try other tools as well. – pgruetter – 2017-10-01T15:40:57.497
1That’s exactly how fast it should be. – Daniel B – 2017-10-01T16:08:25.703
That is the perfect explanation. I never thought that the smaller and the bigger version show such a big difference. So it really is because of the TurboWrite. You could turn your comment into an answer and I'll gladly accept it as the solution. Thanks a lot. – pgruetter – 2017-10-02T06:43:20.600
Please don't edit your question to include a self-answer. Instead, you should post an answer to your own question. – I say Reinstate Monica – 2017-10-03T03:10:50.757
Sorry, changed it. – pgruetter – 2017-10-03T10:20:41.427