I have two SSDs in my laptop:
- Crucial MX300 725GB –> /dev/sda
- SanDisk SSD Plus 240GB –> /dev/sdb
Their performance reads on Linux and Windows like this:
Crucial MX300 –> same on both OSs
sudo hdparm -tT /dev/sda # Crucial
Timing cached reads: 13700 MB in 2.00 seconds = 6854.30 MB/sec
Timing buffered disk reads: 1440 MB in 3.00 seconds = 479.58 MB/sec
SanDisk Plus –> way faster on Windows!
sudo hdparm -tT /dev/sdb # SanDisk
Timing cached reads: 7668 MB in 2.00 seconds = 3834.92 MB/sec
Timing buffered disk reads: 798 MB in 3.00 seconds = 265.78 MB/sec # TOO LOW !!
The sequential read performance of the SanDisk on Linux is about half of its performance on Windows!
My Question is of course: Why and can that be fixed? Is this due to the SanDisk SSD Plus being handled as a SCSI drive?
From syslog:
~$ grep SDSSD /var/log/syslog
systemd[1]: Found device SanDisk_SDSSDA240G
kernel: [ 2.152138] ata2.00: ATA-9: SanDisk SDSSDA240G, Z32070RL, max UDMA/133
kernel: [ 2.174689] scsi 1:0:0:0: Direct-Access ATA SanDisk SDSSDA24 70RL PQ: 0 ANSI: 5
smartd[1035]: Device: /dev/sdb [SAT], SanDisk SDSSDA240G, S/N:162783441004, WWN:5-001b44-4a404e4f0, FW:Z32070RL, 240 GB
smartd[1035]: Device: /dev/sdb [SAT], state read from /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state
smartd[1035]: Device: /dev/sdb [SAT], state written to /var/lib/smartmontools/smartd.SanDisk_SDSSDA240G-162783441004.ata.state
Compared to the Crucial MX300 which has on linux almost the same performance as on Windows:
~$ grep MX300 /var/log/syslog
systemd[1]: Found device Crucial_CT750MX300SSD1
kernel: [ 1.775520] ata1.00: ATA-10: Crucial_CT750MX300SSD1, M0CR050, max UDMA/133
smartd[1035]: Device: /dev/sda [SAT], Crucial_CT750MX300SSD1, S/N:16251486AC40, WWN:5-00a075-11486ac40, FW:M0CR050, 750 GB
smartd[1035]: Device: /dev/sda [SAT], state read from /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state
smartd[1035]: Device: /dev/sda [SAT], state written to /var/lib/smartmontools/smartd.Crucial_CT750MX300SSD1-16251486AC40.ata.state
Any help is very welcome!
Edit:
The difference that hdparm is showing on Linux is very real. I created two identical directories, one in each of the two drives, each directory containing about 25Gb of files (36395 files), and ran the exact same hashdeep checksum creation script on both dirs (the script just creates a md5-checksum for every file in the test dirs and stores all the checksums in one single file). These are the results:
test-sandisk# time create-file-integrity-md5sums.sh .
real 1m49.000s
user 1m24.868s
sys 0m15.808s
test-mx300# time create-file-integrity-md5sums.sh .
real 0m54.180s
user 1m4.628s
sys 0m11.640s
Same test with a single 7Gb file:
test-sandisk# time create-file-integrity-md5sums.sh .
real 0m26.986s
user 0m19.168s
sys 0m3.232s
test-mx300# time create-file-integrity-md5sums.sh .
real 0m17.285s
user 0m16.248s
sys 0m1.368s
Edit 2:
The partitions are "optimal" aligned and the only difference in /sys/block/$disk/queue is discard_zeroes_data (1 on Crucial, 0 on SanDisk).
File system and mount options used: type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)
dmesg | grep -i sata | grep 'link up'
[ 1.936764] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 2.304548] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Best Answer
This may not be a good enough answer, but I am new and can't "comment", and wanted to share with you in case it helps:
I used to work with eMMC flash memories, similar hardware underpinnings as SSD. discard_zeroes_data sounds like it could matter. There were very slow features called Erase and especially Trim (like Erase, but on a 4kB read-block basis instead of the much larger Erase Group Block needed for performance. Later a "Discard" feature was introduced which didn't erase the data to all zeros (really all-ones under the hood, but inverted for your convenience), but just changed the state of the data to "don't care".
So if you did a discard on 4kB of data, it was faster because didn't do an erase, but let the firmware know that you didn't need the data anymore, and it kept track of that physical area in a table. This allowed the garbage collection type of mechanism to reclaim that data location (likely re-map it to a different address) later when enough of its neighbours could be erased, copying any needed data to another area as needed and then doing the expensive "Erase" operation in the background.
TBH we ended up disabling discard at first, because it didn't work so well in and caused us performance issues when too much data was left in discard state, and the physical erases never happened.
So I can't tell what "discard_zeros_data" exactly means, but if I were you I'd definitely try changing it to the opposite state and see what happens. If it reads like "subject verb object", then it could be a security feature where it takes the time to forcibly erase even small bits of data (expensive) so that there's no chance that someone can reclaim your old files after you think you've deleted them. I would think that setting this to "Zero" would actually increase performance, if that's how you read it, but you're seeing the opposite.
Also try doing the biggest forcible "erase" that you are able to, whether using special SSD tools, or a full format, or something, and see if the performance is better right after this erase. That will at least give you some information about the problem.
The filesystem type should definitely matter also, but I think this is a constant in your two experiments.