SanDisk CloudSpeed Eco 1.92TB 2.5" SATA $120

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

A33

New Member
Mar 16, 2023
14
12
3
Thanks. It's clear I'm not that proficient in Ebay search... I clicked on the seller's name and it said that they were sold out. However on your link he/she is still selling the same drives.
 

Markess

Well-Known Member
May 19, 2018
1,151
768
113
Northern California
Thanks. It's clear I'm not that proficient in Ebay search... I clicked on the seller's name and it said that they were sold out. However on your link he/she is still selling the same drives.
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.
 

SnJ9MX

Active Member
Jul 18, 2019
117
70
28
Thanks. It's clear I'm not that proficient in Ebay search... I clicked on the seller's name and it said that they were sold out. However on your link he/she is still selling the same drives.
easiest way to search for these is just search for "1.92tb". plenty pop up
 
  • Like
Reactions: Markess

Flintstone

Member
Jun 11, 2016
127
20
18
47
I got my two disks and I can't say that I'm impressed with the speed. Feel like its better to focus on $70 Intel 1.6tb PCIe/NVMe with 1.2GB/s instead of these with 250MB/s for $40... Of course PCIe slots are limited - but then it's just a matter of how many servers you have :)
 
  • Like
Reactions: Fritz

Fritz

Well-Known Member
Apr 6, 2015
3,377
1,384
113
70
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.
 

A33

New Member
Mar 16, 2023
14
12
3
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?
 

Flintstone

Member
Jun 11, 2016
127
20
18
47
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...
 

Flintstone

Member
Jun 11, 2016
127
20
18
47
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/s
Benchmarking is hard...
 

nexox

Well-Known Member
May 3, 2023
631
251
63
I 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:

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/s
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.
 

EasyRhino

Well-Known Member
Aug 6, 2019
506
376
63
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
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!
 

UhClem

just another Bozo on the bus
Jun 26, 2012
436
250
63
NH, USA
Some SSDs have optimizations for blocks of all zeros,
sort of like a TRIM, which is why I use /dev/urandom.
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:

nexox

Well-Known Member
May 3, 2023
631
251
63
Dubious. Please provide a (properly documented) example/test that supports this.
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.
 

UhClem

just another Bozo on the bus
Jun 26, 2012
436
250
63
NH, USA
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.
Dubious. Please provide a (properly documented) example/test that supports this.
Still dubious ...