There are plenty more, SanDisk CloudSpeed Eco 1.92TB SATA 2.5" Solid State Drive | eBay
SanDisk CloudSpeed Eco 1.92TB 2.5" SATA $120
- Thread starter foureight84
- Start date
Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.
This seller seems to post things in batches. When they get additional stock for an item, they tend to create a new listing rather than increasing the quantity on an existing listing. So if you follow a link and a a batch is sold out, you can always check “Seller’s Other Items” to see if a new listing is up.
On a related note, I bought a couple of M.2 2280 NVMe drives and USB enclosures. These are by far the fastest USB drives I have ever had. I thought the interface was the limiting factor but i guess not.
Really depends on what you need, half the price per TB and hot swap in any old server chassis make them quite compelling to me.
Power consumption is also going to be killer on NVMe compared to SATA drives.
I just bought myself a new office PC where I a stripe of 4 of these. Good enough performance for me and a few VM's 
Just tested one of the 4 I have received. It comes with firmware version ZR03. After testing it with DiskSpeed (formatted as btrfs temporary) it gives:
800-861MB/s read
684-738MB/s write
It comes with reported 93% life remaining. For what I paid more than good enough.
I might try updating the firmware as it seems there are some improvements to recycling algorithm that might improve lifespan (changelog). Any idea how can I extract current firmware in case the newer version gives me worse performance?
800-861MB/s read
684-738MB/s write
It comes with reported 93% life remaining. For what I paid more than good enough.
I might try updating the firmware as it seems there are some improvements to recycling algorithm that might improve lifespan (changelog). Any idea how can I extract current firmware in case the newer version gives me worse performance?
Since SATA3 only supports up to 600MB/s, I think something has to be wrong with your benchmarking method? I usually use raw DD from /dev/zero without compression with different block sizes to test - not a foolproof method, but at least gives me an idea - and is something I have used as an initial test (for better and worse) since I started with ZFS on Solaris almost 20 years ago...
Some SSDs have optimizations for blocks of all zeros, sort of like a TRIM, which is why I use /dev/urandom.
You must have a faster system then mine then - urandom doesn't seem like a fast source on my E5 v4 cpu at least.
Code:
root@prox-marty:~# dd if=/dev/urandom of=/dev/null bs=4096000 count=1000
1000+0 records in
1000+0 records out
4096000000 bytes (4.1 GB, 3.8 GiB) copied, 14.257 s, 287 MB/sI do have a pair of Xeon 6132s in my test system, but even an E5 2690 v2 in another machine can generate urandom faster than that:
That said, yeah, a better way to throw random-enough data at an SSD is to generate a series of 4k pages of random data, then as you write to the device XOR the first 32 or 64 bits of a page with the offset that the page is written, that's a much less CPU-intensive way to defeat the various compression and deduplication methods that SSD controllers might use to cheat on benchmarks. Unfortunately the bit of code I have to do that is so ancient it won't even kind of compile on anything newer than CentOS 6, and I don't feel like messing with it.
Still, waiting for urandom to write at least makes subsequent read benchmarks valid, the controller can't take any shortcuts returning blocks of zeros that it never wrote to begin with.
Code:
root@prx:~# dd if=/dev/urandom of=/dev/null bs=4096000 count=1000
1000+0 records in
1000+0 records out
4096000000 bytes (4.1 GB, 3.8 GiB) copied, 11.9968 s, 341 MB/sStill, waiting for urandom to write at least makes subsequent read benchmarks valid, the controller can't take any shortcuts returning blocks of zeros that it never wrote to begin with.
dont use urandom directly when you want to test your ssd
write a file to for example a ram drive(tmpfs) or nvme drive with urandom, and then write it to the ssd
write a file to for example a ram drive(tmpfs) or nvme drive with urandom, and then write it to the ssd
OMG that's genius. I was also trying to figure out an faster was to do a dd random benchmark, without needed to learn fio or something... and tmpfs is genius. Dumpma 1gb file in tmpfs and just repeatedly write the drive with dd!
Dubious. Please provide a (properly documented) example/test that supports this. [Specifications (ATA & NVMe) dictate that a WRITE (device cmd) results in a write to the media.] [[EDIT/correction: NVMe does have an optional Wriite_Zeroes; see Link]]
One does have to be careful, in READ testing, to ensure that no virgin blocks (never been written) are part of the read sample.
Last edited:
I don't have access to the worse of these drives any more, but the first couple generations of Sandforce controller definitely did this, pretty sure they advertised it as a feature.
Pny cs3030, which I have, does something similar
www.pcworld.com
It can write zeros all day long at 1.7GBs but random is a lot slower.
PNY XLR8 CS3030 NVMe SSD review: Cheap and exceptionally fast for everyday chores
PNY's CS3030 NVMe SSD is a great everyday performer. For the average user, it's a bargain, but it slows more than usual for a bargain drive during long writes.
www.pcworld.com
It can write zeros all day long at 1.7GBs but random is a lot slower.