M.2 SSD help sought - Page 2

bhelmes · 2021-05-28, 18:25

Quote:

Originally Posted by PhilF

How much data have you written to it?

Linux mint needs 12 Gbyte space on the disk, without any optimations.

I think you can add a pci-card for 2 or 4 M.2 cards for every pci-slot.

It may be interesting how long the M.2 card holds.

I bought 64 Gbyte ram (expensive) and a M.2 card (cheap) in order to run my programs in the first level cache.

PhilF · 2021-05-28, 19:19

Quote:

Originally Posted by bhelmes

I think you can add a pci-card for 2 or 4 M.2 cards for every pci-slot.

...

I bought 64 Gbyte ram (expensive) and a M.2 card (cheap) in order to run my programs in the first level cache.

Uhm, that's not quite how it works. For a M.2 card to operate anywhere close to level 3 cache speed, it has to be installed in a motherboard that has a special M.2 slot. That way it is attached directly to the processor's bus and can operate at full speed.

I'm not saying you can't get PCI cards that holds M.2 cards, but I am saying if you use them in that manner it makes accessing the data on them much slower, closer to standard SSD speed.

chalsall · 2021-05-28, 20:09

Quote:

Originally Posted by kriesel

Well there was that one time I formatted a 1TB rotating rust Seagate in an external USB enclosure, and that was the end of being able to access it.

Please don't get me started on SeaCrap...

Quote:

Originally Posted by kriesel

Too late for me. Good advice for other potential buyers.

Indeed. I also learnt something here. Never would have thought of that!

Quote:

Originally Posted by kriesel

The jury's out yet on the 2TB; no errors shown yet at over 190GB / 10%. Write rates are poor, ~4-8MB/sec oscillating at ~1Hz.

I was interested in just how bad that was, so quickly ran some experiments...

Burrow is my main workstation (M2.SSD attached to the MB and polished rust). ArchitectsCubed is a certain client's public-facing VPS with SSD.

Code:

[root@burrow tests]# dd if=/dev/zero of=sixteen_gig.zeros bs=1G count=16 oflag=dsync
16+0 records in
16+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 25.3828 s, 677 MB/s

[root@burrow tests]# dd if=sixteen_gig.zeros of=/dev/null bs=1G count=16 oflag=dsync
16+0 records in
16+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 7.79819 s, 2.2 GB/s

[root@burrow tests_rust]# dd if=/dev/zero of=sixteen_gig.zeros bs=1G count=16 oflag=dsync
16+0 records in
16+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 141.977 s, 121 MB/s

[root@burrow tests_rust]# dd if=sixteen_gig.zeros of=/dev/null bs=1G count=16 oflag=dsync
16+0 records in
16+0 records out
17179869184 bytes (17 GB, 16 GiB) copied, 122.485 s, 140 MB/s


root@architectscubed tests]# dd if=/dev/zero of=sixteen_gig.zeros bs=1G count=16 oflag=dsync
16+0 records in
16+0 records out
17179869184 bytes (17 GB) copied, 34.4538 s, 499 MB/s

[root@architectscubed tests]# dd if=sixteen_gig.zeros of=/dev/null bs=1G count=16 oflag=dsync
16+0 records in
16+0 records out
17179869184 bytes (17 GB) copied, 31.1031 s, 552 MB/s

Quote:

Originally Posted by kriesel

If there's interest, I could follow up with a "2TB SSD" testing update later.

Please. We learn faster together!

chalsall · 2021-05-28, 21:15

Quote:

Originally Posted by chalsall

I was interested in just how bad that was, so quickly ran some experiments...

Sorry, everyone. I realized an assumed variable not given...

kriesel's low bandwidth /could/ be because of the USB interconnect, not the "SSD" actually provisioned...

If I may please say Ken... I can't wait to see you crack those products open and post the pictures here. Just to see what you were sold...

Learning opportunities abound. Add this to your reference material...

Seriously...

kriesel · 2022-01-31, 03:28

Lots of detail posted beginning here in the "hall of shame" reference thread. The system was set up with a rotating HD instead.

Quote:

Originally Posted by retina

In Linux there are tools like lsblk -nrdbo SIZE /dev/sda that display the hardware size and will ignore any file system data. You can use that to query the real size.

FWIW, plugging the "2TB" fake into a Centos 7.9 system and using that command returns 2097152000000.

retina · 2022-01-31, 04:12

Quote:

Originally Posted by kriesel

FWIW, plugging the "2TB" fake into a Centos 7.9 system and using that command returns 2097152000000.

Is that an HDD or an SSD? What is the labelling on the drive? What is the tested size?

If you get fake results from the low level drive data then that means someone is reprogramming the drive firmware (or the USB controller chip if it is an external drive).

kriesel · 2022-01-31, 10:02

USB "3.1" packaged external "2TB" "SSD" that indicates in testing as USB 2.0 58 GiB class 10 flash memory.
Excerpts from "2TB SSD detail" reference post:

Code:

While the "2TB SSD" is connected to a USB 3.1 port, MediaTester v0.4.1.0 with local data
generation gives ~10 MB/sec write, ~30.7 MB/sec read, and first failing readback byte at 
62,657,265,664 (~58.35 GiB).

Code:

Protocal Version: USB 2.00

Code:

Controller Vendor: FirstChip
Controller Part-Number: FC1178BC
Flash ID code:      983C98B376F2 - Toshiba - 2CE/Single Channel [TLC] -> Total Capacity = 64GB

Code:

Flash ID mapping table
----------------------------
[Channel 0]    [Channel 1]
983C98B376F2    --------
983C98B376F2    --------
989898989898    --------
989898989898    --------
989898989898    --------
989898989898    --------
989898989898    --------
989898989898    --------

See also photos attached here.

retina · 2022-01-31, 10:11

Quote:

Originally Posted by kriesel

Code:

Flash ID code:      983C98B376F2 - Toshiba - 2CE/Single Channel [TLC] -> Total Capacity = 64GB

So it hasn't been reprogrammed.

Then there is no need to waste time testing the read/write speeds, just look at the factory data. Within a few seconds you can already know it is just fake packaging for a smaller device.

So using lsblk on that returns 2TB? What does blkid show?

kriesel · 2022-01-31, 10:50

Quote:

Originally Posted by retina

Then there is no need to waste time testing the read/write speeds, just look at the factory data. Within a few seconds you can already know it is just fake packaging for a smaller device.

So using lsblk on that returns 2TB? What does blkid show?

Within seconds after becoming suspicious enough and either setting up and logging in to a real Linux system and learning the necessary commands, or hunting up and installing the Windows test programs I found useful.
Excerpting only to headers & output relevant to the device of interest, and note the label shown is one I entered in the final reformat in preparation for return;

Code:

$ sudo blkid
/dev/sdb: LABEL="2TB-63GB" UUID="DE95-EEE1" TYPE="exfat" PTTYPE="dos"
$ lsblk
NAME  MAJ:MIN  RM  SIZE  TYPE  MOUNTPOINT
sdb    8:16     1  1.9T  disk

retina · 2022-01-31, 11:03

lsblk is fooled also.

That's some deeper voodoo than the usual exFAT modifications.

I wonder which tool can reliably see through that?

kriesel · 2022-01-31, 11:31

Quote:

Originally Posted by retina

I wonder which tool can reliably see through that?

Various on Windows. Hunting about a bit for Linux, I found this which may help.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Low-powered motherboard of adequate capability sought	fivemack	Hardware	1	2011-12-21 19:26
Feedback for new MPQS utility sought	jasonp	Msieve	308	2007-02-21 05:43

2022-01-31, 11:03	#21
retina Undefined "The unspeakable one" Jun 2006 My evil lair 6,793 Posts	lsblk is fooled also. That's some deeper voodoo than the usual exFAT modifications. I wonder which tool can reliably see through that?