I have recently installed openSUSE 13.2 on a new Verbatim Store 'N Go 128 GB SSD USB3. Compared with the same system installed on an external USB2 HD and plugged in the same computer, openSUSE from the new SSD is very slow, and the system often freezes for a spell (up to 20-30 seconds). I have checked the SSD disk connected to a USB2 port using both hdparm and dd, the results are as follows:
hdparm:
V500:~ # hdparm -tT /dev/sdc
/dev/sdc:
Timing cached reads: 7632 MB in 2.00 seconds = 3817.97 MB/sec
Timing buffered disk reads: 104 MB in 3.00 seconds = 34.63 MB/sec
dd (write):
V500:/mnt # dd if=/dev/zero of=./testfile bs=1M count=1024 conv=fdatasync,notrunc
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 66.8925 s, 16.1 MB/s
dd (read, after purging the cache):
V500:/mnt # dd if=./testfile of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 29.9146 s, 35.9 MB/s
The read speed (about 35 MB/s) is similar to what I get with the older external HD, but the write speed is much lower (I get about 35 MB/s with the older HD). Any suggestion? There is some setting that can be adjusted, or is it just a defective SSD?
Thank you! I knew that I could not expect top speed, that’s why I was not worried about the 30 MB/s read speed. Write speed at 15 MB/s is really low, though, less than what I get with an older mechanical HD. From what you say, I understand that the problem may be the kernel, not the hardware itself. Is there a way to test a 4.X kernel? I have no clue about how to do it. And yes, I know that running an OS from an external USB disk is not a good idea in general, but it’s the only way I have at the moment to have a decent OS and software collection on my work computer!
Write speed are generally slower. Flash is a funny animal. It does not work as you expect it would. Though I find those speed slow. This is real SSD and not just a fancy flash stick??? The specs I see are pretty slim.
Thank you for your support. I can’t tell about the hardware, they sold it as a SSD. Any way to check? I’ll try and see what happens with the new kernel and let you know.
Although it has been many years, I’ve run earlier versions of openSUSE just fine from an external USB2 disk if I wasn’t doing any major file transfers. IMO the disk connection should be even less of a problem with recent openSUSE versions due to extensive use of tempfs for mounts that used to be mounted to disk.
The symptoms you describe strongly suggest that you have a disk “write amplification” issue, which exists because SSDs require an extra step before writing… When data is erased, the solid state “traps” aren’t available for writing immediately like HDD. On an HDD sectors marked for deletion are simply over-written but on an SSD need to be “erased,” ie. contents set to null. Only then can new data be written.
So, in your case this means…
The “new” SSD drive you bought probably isn’t <factory> brand new when all traps are set to null and ready to be written. Your disk has been used before (or you’ve already written substantial amounts of data to the drive) and the TRIM operation to erase the traps hasn’t yet been executed. This results in your periodic stop/pause as your disk has to perform the TRIM operation on demand which is time consuming. Under normal operations and if properly configured, TRIM operations are executed periodically and usually as a background process so that when you want to write, a sufficient number of erased traps are available.
AFAIK openSUSE today installs only file systems that support TRIM by default unless you do something unusual… like go out of your way to install on an unusual file system or instead of installing new on your SSD you clone an image from an HDD to an SSD in which case although the file systems would support SSD, the automatic TRIM operations are not enabled. If either of these or similar apply to you, you will have to manually enable TRIM.
There is another possibility I haven’t investigated that because you’re installed on an external drive, it might not be recognized as an “internal system” drive so different maintenance policies including whether to run TRIM regularly might be different. Don’t know about this, but just mentioning as a possibility.
In any case, it sounds like you should manually run a TRIM operation for now after emtying your trash defragging or any other major operation to remove unnecessary files (to maximize the amount of free space you want to prepare).
Of special note for you at the moment is the description and use of ATA_TRIM to manually set your SSD traps.
You should also look for any published firmware updates specific to your SSD.
Thank you for all the info! I decided to check this TRIM thing before installing a new kernel as suggested by gogalthorp. I followed the instruction in the Arch Linux Wiki, and this what I ended up with:
If you Google Store 'N Go you find a lot of stick and at least on called and SSD. Very confusing I think they just packaged a stick in a more drive like box. The difference between a stick and an SSD is the controller. A SSD should look like a HD to the system. A stick looks like a USB memory device. That is why I wondered if it was a true SSD or just some market glitz
Thanks Carlos. The disk does support hdparm queries, or at least it supports hdparm -tT (see beginning of this thread). Maybe sticks support some hdparm commands, but not others? Later today I’ll check hdparm without the pipe.
Hi everybody, this is the full output of the hdparm -I command. The disk is showing even more signs of malfunctioning (today I could not get the desktop, just tty), I am going to return it tomorrow as I think it’s flawed. Thank you all for your help.
SG_IO: bad/missing sense data, sb]: 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ATA device, with non-removable media
Model Number: ��E����������������� ����
�
Serial Number: ���Ep��������
Firmware Revision: ���
�
Standards:
Used: unknown (minor revision code 0x01f4)
Supported: 14 13 12 11 10 9 8 7 6
Likely used: 14
Configuration:
Logical max current
cylinders 0 0
heads 0 0
sectors/track 510 0
--
Logical/Physical Sector size: 512 bytes
device size with M = 1024*1024: 0 MBytes
device size with M = 1000*1000: 0 MBytes
cache/buffer size = unknown
Capabilities:
IORDY(may be)(cannot be disabled)
Queue depth: 32
Standby timer values: spec'd by Vendor
R/W multiple sector transfer: Max = 255 Current = 255
DMA: *mdma0 *mdma1 *mdma2 *mdma3 *mdma4 *mdma5 *mdma6 *mdma7 (?)
Cycle time: min=498ns recommended=59904ns
PIO: pio0 pio1 pio2
Cycle time: no flow control=65535ns IORDY flow control=32544ns
* reserved 69[2]
* reserved 69[4]
* reserved 69[6]
* reserved 69[7]
* DOWNLOAD MICROCODE DMA command
Integrity word not set (found 0x0000, expected 0x3fa5)
I don’t know of any way other then getting the full specs from the vendor not just a advertisement blurb. Having both sticks and supposed SSD’s called Store 'N Go makes you wonder if they are using the same tech. SSD’s generally have superior control algorithms and circuitry. I would not think you would lump them together. Maybe you can find a review???
On 2015-08-30 18:06, Cpedone wrote:
>
> Hi everybody, this is the full output of the hdparm -I command. The disk
> is showing even more signs of malfunctioning (today I could not get the
> desktop, just tty), I am going to return it tomorrow as I think it’s
> flawed. Thank you all for your help.
>
>
> Code:
> --------------------
> ATA device, with non-removable media
> Model Number: ��E����������������� ����
> �
> --------------------
Are you getting those strange question marks, or did you write them for
obfuscation of private data? :-??
Well, if the thing is incapable of displaying the model number, things
are very strange.
No, no privacy issues, that’s what I got in the output!! My idea is that you were right and it was probably something that looked like a SSD, but wasn’t. Anyway, this morning I returned it to Amazon.
Thank you for all your support, at least I’ve learned a few things about checking HD performance!