Re: testing new sdm drive

[David Wright]

On Tue 26 Mar 2024 at 04:38:52 (-0400), gene heskett wrote:
> On 2/9/24 20:36, Alexander V. Makartsev wrote:
[ … ]
> > It's not possible for me to know what went wrong.
> > Have you created "reftestfile" inside "/mnt/disktest" directory?
> > How many "testfile*" files, if any, were created on the filesystem
> > mounted at "/mnt/disktest"?
> > Was there anything relevant in the syslog about "sdm" drive after the test?
> > If you'd followed my instructions step by step, you'd end up
> > inside "/mnt/disktest" directory and for the last step all you had
> > to do is copy and paste that one-liner 'for' loop into the command
> > line.
> > It's a long line and it really meant to be copied and pasted not
> > typed by hand, and also to give you the idea of the process, so
> > you could adjust it if needed.
> > I've tested it again on my computer and it worked as expected,
> > synchronously created "testfiles" inside current directory and
> > calculated their hashes one by one.
> > 
> And by now, I've forgotten what it was that we were trying to
> accomplish.  One of the hazards of my next b-day being the 90'th.
> Sorry. Or t-bird is messing  with my mind by reserectiing older messages.

You seem to have mislaid your first reply to Alexander, at:
  https://lists.debian.org/debian-user/2024/02/msg00422.html
which appears to show that the drive was a dud 64GB disk, and
not 2TB in capacity.

Cheers,
David.

Re: testing new sdm drive

[gene heskett]

On 2/9/24 20:36, Alexander V. Makartsev wrote:

On 10.02.2024 03:34, gene heskett wrote:

On 2/8/24 07:22, Alexander V. Makartsev wrote:

This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
 $ sudo gdisk /dev/sdX check

/!\  Make double sure you've selected the right device by using 
"lsblk" and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" 
to create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w". check


Next format partition to ext4 filesystem:
 $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1 check

Next mount the filesystem:
 $ sudo mkdir /mnt/disktest check
 $ sudo mount /dev/sdX1 /mnt/disktest check

Next create reference 1GB file filled with dummy data:
 $ cd /mnt/disktest check
 $ sudo fallocate -l 1G ./reftestfile check
 $ sudo badblocks -w -s -t random ./reftestfile check

Now we can use script to create 1830 1GB files and check their checksum:
 $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to 
checksum of "reftestfile":

 $ md5sum -b ./reftestfile

Got a problem Alexander:
I had to put the script someplace else. So I put it in my private 
/home/gene/bin as disktest.txt with nano. couldn't find it.

But:
gene@coyote:/mnt/disktest$ sudo /home/gene/bin/disktest.txt
sudo: /home/gene/bin/disktest.txt: command not found
If you put that 'for' loop one-liner inside, I think you forgot to make 
"/home/gene/bin/disktest.txt" executable:

     $ chmod +x /home/gene/bin/disktest.txt


And:
gene@coyote:/mnt/disktest$ ls /home/gene/bin/disktest.txt
/home/gene/bin/disktest.txt
So I think I found the problem with my script, ancient eyeballs can't 
tell the diff between () and{} so I fixed that but it still won't run 
or be killed. I don't care how big you've made the t-bird font, by the 
time you've read 2 more msgs, its back to about 6 point text.  Grrr.


So I fired up a root session of htop, found about 8 copies of dd 
showing and started killing them but cannot kill the last 2 in the D 
state.


And cannot find .disktest.txt running in a root htop and the2 copy's 
of dd can't be killall'd.



It's not possible for me to know what went wrong.
Have you created "reftestfile" inside "/mnt/disktest" directory?
How many "testfile*" files, if any, were created on the filesystem 
mounted at "/mnt/disktest"?

Was there anything relevant in the syslog about "sdm" drive after the test?
If you'd followed my instructions step by step, you'd end up inside 
"/mnt/disktest" directory and for the last step all you had to do is 
copy and paste that one-liner 'for' loop into the command line.
It's a long line and it really meant to be copied and pasted not typed 
by hand, and also to give you the idea of the process, so you could 
adjust it if needed.
I've tested it again on my computer and it worked as expected, 
synchronously created "testfiles" inside current directory and 
calculated their hashes one by one.


And by now, I've forgotten what it was that we were trying to 
accomplish.  One of the hazards of my next b-day being the 90'th.

Sorry. Or t-bird is messing  with my mind by reserectiing older messages.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive continued

[David Christensen]

On 2/10/24 08:25, gene heskett wrote:

I managed to kill f3write, so f3probe could access it:
ene@coyote:/mnt/disktest$ sudo f3probe --destructive --time-ops /dev/sdm
F3 probe 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
  it can take longer. Please be patient.

Bad news: The device `/dev/sdm' is a counterfeit of type limbo

You can "fix" this device using the following command:
f3fix --last-sec=124050943 /dev/sdm

Device geometry:
  *Usable* size: 59.15 GB (124050944 blocks)
     Announced size: 1.91 TB (409600 blocks)
     Module: 2.00 TB (2^41 Bytes)
     Approximate cache size: 1.00 MB (2048 blocks), need-reset=no
    Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 2.07s
  Operation: total time / count = avg time
   Read: 311.9ms / 4212 = 74us
  Write: 1.75s / 24740 = 70us
  Reset: 1us / 1 = 1us
gene@coyote:/mnt/disktest$
No faster than it is, its not worth the f3fix effort, I can buy 
reputable, much faster sd cards at 1/3rd the cost.



Okay -- here is the thread Thomas referenced.  It has not hit the 
archive servers yet.



The f3probe results are bad news, but not unexpected.  At least you have 
a definite answer that you can send to the seller and/or Amazon (?).



David

Re: testing new sdm drive

[gene heskett]

On 2/10/24 00:46, David Christensen wrote:

On 2/9/24 00:51, gene heskett wrote:

On 2/8/24 13:25, David Christensen wrote:

On 2/7/24 23:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
...
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

 >> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta
...
Please try again with the drive connected directly to a motherboard 
USB 3.0 port.



That is where it still is, on a blue usb3.0 port on a 3 yo ASUS mobo.



Does smartctl(8) fail when you connect the USB SSD to other USB ports?

Allready packed up for return, I found enough fraud with the f3 package 
to jail somebody.


David

.


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[gene heskett]

On 2/9/24 20:37, Alexander V. Makartsev wrote:

On 10.02.2024 03:34, gene heskett wrote:

On 2/8/24 07:22, Alexander V. Makartsev wrote:

This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
 $ sudo gdisk /dev/sdX check

/!\  Make double sure you've selected the right device by using 
"lsblk" and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" 
to create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w". check


Next format partition to ext4 filesystem:
 $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1 check

Next mount the filesystem:
 $ sudo mkdir /mnt/disktest check
 $ sudo mount /dev/sdX1 /mnt/disktest check

Next create reference 1GB file filled with dummy data:
 $ cd /mnt/disktest check
 $ sudo fallocate -l 1G ./reftestfile check
 $ sudo badblocks -w -s -t random ./reftestfile check

Now we can use script to create 1830 1GB files and check their checksum:
 $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to 
checksum of "reftestfile":

 $ md5sum -b ./reftestfile

Got a problem Alexander:
I had to put the script someplace else. So I put it in my private 
/home/gene/bin as disktest.txt with nano. couldn't find it.

But:
gene@coyote:/mnt/disktest$ sudo /home/gene/bin/disktest.txt
sudo: /home/gene/bin/disktest.txt: command not found
If you put that 'for' loop one-liner inside, I think you forgot to make 
"/home/gene/bin/disktest.txt" executable:

     $ chmod +x /home/gene/bin/disktest.txt


And:
gene@coyote:/mnt/disktest$ ls /home/gene/bin/disktest.txt
/home/gene/bin/disktest.txt
So I think I found the problem with my script, ancient eyeballs can't 
tell the diff between () and{} so I fixed that but it still won't run 
or be killed. I don't care how big you've made the t-bird font, by the 
time you've read 2 more msgs, its back to about 6 point text.  Grrr.


So I fired up a root session of htop, found about 8 copies of dd 
showing and started killing them but cannot kill the last 2 in the D 
state.


And cannot find .disktest.txt running in a root htop and the2 copy's 
of dd can't be killall'd.



It's not possible for me to know what went wrong.
Have you created "reftestfile" inside "/mnt/disktest" directory?
How many "testfile*" files, if any, were created on the filesystem 
mounted at "/mnt/disktest"?

Was there anything relevant in the syslog about "sdm" drive after the test?
If you'd followed my instructions step by step, you'd end up inside 
"/mnt/disktest" directory and for the last step all you had to do is 
copy and paste that one-liner 'for' loop into the command line.
It's a long line and it really meant to be copied and pasted not typed 
by hand, and also to give you the idea of the process, so you could 
adjust it if needed.
I've tested it again on my computer and it worked as expected, 
synchronously created "testfiles" inside current directory and 
calculated their hashes one by one.


Someone else advised me of the f3 package, designed to do exactly this, 
disclosed that the first one tested was actually an undersized and slow 
64G drive. Got them packed up and return authorization already for a 
mailing label,  Thank you very much for your assistance Alexander, 
interest much apprecaited.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive continued

[gene heskett]

On 2/8/24 15:36, Linux-Fan wrote:

Alexander V. Makartsev writes:


[...]
I managed to kill f3write, so f3probe could access it:
ene@coyote:/mnt/disktest$ sudo f3probe --destructive --time-ops /dev/sdm
F3 probe 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
 it can take longer. Please be patient.

Bad news: The device `/dev/sdm' is a counterfeit of type limbo

You can "fix" this device using the following command:
f3fix --last-sec=124050943 /dev/sdm

Device geometry:
 *Usable* size: 59.15 GB (124050944 blocks)
Announced size: 1.91 TB (409600 blocks)
Module: 2.00 TB (2^41 Bytes)
Approximate cache size: 1.00 MB (2048 blocks), need-reset=no
   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 2.07s
 Operation: total time / count = avg time
  Read: 311.9ms / 4212 = 74us
 Write: 1.75s / 24740 = 70us
 Reset: 1us / 1 = 1us
gene@coyote:/mnt/disktest$
No faster than it is, its not worth the f3fix effort, I can buy 
reputable, much faster sd cards at 1/3rd the cost.




HTH
Linux-Fan

öö

[...]

c
Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[gene heskett]

On 2/8/24 15:36, Linux-Fan wrote:

Alexander V. Makartsev writes:


On 08.02.2024 12:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
http://www.smartmontools.org>www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0


[...]

Looks like a scam. Probably a reprogrammed controller to falsely 
report 2TB of space to the system.


I support this view :)


This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
    $ sudo gdisk /dev/sdX

/!\  Make double sure you've selected the right device by using 
"lsblk" and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" to 
create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w".


Next format partition to ext4 filesystem:
    $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1

Next mount the filesystem:
    $ sudo mkdir /mnt/disktest
    $ sudo mount /dev/sdX1 /mnt/disktest

Next create reference 1GB file filled with dummy data:
    $ cd /mnt/disktest



From here on I'd suggest trying the tools from package `f3`.


After installing it, find the documentation under
/usr/share/doc/f3/README.rst.gz. Basic usage requires only two commands:

 f3write .

Which has now stopped after severa hours of quitelatharic speeds in the 
20m/second are, showing a litle over 1.5%.  The bash shell shows it has 
written:

ree space: 1.87 TB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Creating file 5.h2w ... OK!
Creating file 6.h2w ... OK!
Creating file 7.h2w ... OK!
Creating file 8.h2w ... OK!
Creating file 9.h2w ... OK!
Creating file 10.h2w ... OK!
Creating file 11.h2w ... OK!
Creating file 12.h2w ... OK!
Creating file 13.h2w ... OK!
Creating file 14.h2w ... OK!
Creating file 15.h2w ... OK!
Creating file 16.h2w ... OK!
Creating file 17.h2w ... OK!
Creating file 18.h2w ... OK!
Creating file 19.h2w ... OK!
Creating file 20.h2w ... OK!
Creating file 21.h2w ... OK!
Creating file 22.h2w ... OK!
Creating file 23.h2w ... OK!
Creating file 24.h2w ... OK!
Creating file 25.h2w ... OK!
Creating file 26.h2w ... OK!
Creating file 27.h2w ... OK!
Creating file 28.h2w ... OK!
Creating file 29.h2w ... OK!
Creating file 30.h2w ... OK!
Creating file 31.h2w ... OK!
Creating file 32.h2w ... OK!
Creating file 33.h2w ... OK!
Creating file 34.h2w ... OK!
Creating file 35.h2w ... OK!
Creating file 36.h2w ... OK!
Creating file 37.h2w ... OK!
Creating file 38.h2w ... OK!
Creating file 39.h2w ... 1.98% -- 1.90 MB/s -- 257:11:32

but is taking a few bytes now and then. I 'd thing if f3write was having 
a problem, it would exist with a report. An ls -l in another shell took 
about two minutes to respond:

gene@coyote:/mnt/disktest$ ls -l
total 40627044
-rw--- 1 root root 1073741824 Feb 10 05:49 10.h2w
-rw--- 1 root root 1073741824 Feb 10 05:51 11.h2w
-rw--- 1 root root 1073741824 Feb 10 05:59 12.h2w
-rw--- 1 root root 1073741824 Feb 10 06:16 13.h2w
-rw--- 1 root root 1073741824 Feb 10 06:25 14.h2w
-rw--- 1 root root 1073741824 Feb 10 06:33 15.h2w
-rw--- 1 root root 1073741824 Feb 10 06:44 16.h2w
-rw--- 1 root root 1073741824 Feb 10 06:45 17.h2w
-rw--- 1 root root 1073741824 Feb 10 06:57 18.h2w
-rw--- 1 root root 1073741824 Feb 10 07:06 19.h2w
-rw--- 1 root root 1073741824 Feb 10 05:22 1.h2w
-rw--- 1 root root 1073741824 Feb 10 07:16 20.h2w
-rw--- 1 root root 1073741824 Feb 10 07:22 21.h2w
-rw--- 1 root root 1073741824 Feb 10 07:32 22.h2w
-rw--- 1 root root 1073741824 Feb 10 07:35 23.h2w
-rw--- 1 root root 1073741824 Feb 10 07:39 24.h2w
-rw--- 1 root root 1073741824 Feb 10 07:50 25.h2w
-rw--- 1 root root 1073741824 Feb 10 08:09 26.h2w
-rw--- 1 root root 1073741824 Feb 10 08:19 27.h2w
-rw--- 1 root root 1073741824 Feb 10 08:29 28.h2w
-rw--- 1 root root 1073741824 Feb 10 08:31 29.h2w
-rw--- 1 root root 1073741824 Feb 10 05:24 2.h2w
-rw--- 1 root root 1073741824 Feb 10 08:37 30.h2w
-rw--- 1 root root 1073741824 Feb 10 08:57 31.h2w
-rw--- 1 root root 1073741824 Feb 10 09:06 32.h2w
-rw--- 1 root root 1073741824 Feb 10 09:32 33.h2w
-rw--- 1 root root 1073741824 Feb 10 09:42 34.h2w
-rw--- 1 root root 1073741824 Feb 10 10:00 35.h2w
-rw--- 1 root root 1073741824 Feb 10 10:11 36.h2w
-rw--- 1 root root  799719936 Feb 10 10:21 37.h2w
-rw--- 1 root root 1073741824 Feb 10 05:26 3.h2w
-rw--- 1 root root 1073741824 Feb 10 05:29 4.h2w
-rw--- 1 root root 1073741824 Feb 10 05:31 5.h2w
-rw--- 1 root root 1073741824 Feb 10 05:33 6.h2w

Re: testing new sdm drive

[David Christensen]

On 2/9/24 00:51, gene heskett wrote:

On 2/8/24 13:25, David Christensen wrote:

On 2/7/24 23:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
...
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

 >> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta
...
Please try again with the drive connected directly to a motherboard 
USB 3.0 port.



That is where it still is, on a blue usb3.0 port on a 3 yo ASUS mobo.



Does smartctl(8) fail when you connect the USB SSD to other USB ports?


David

Re: testing new sdm drive

[Alexander V. Makartsev]

On 10.02.2024 03:34, gene heskett wrote:

On 2/8/24 07:22, Alexander V. Makartsev wrote:

This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
 $ sudo gdisk /dev/sdX check

/!\  Make double sure you've selected the right device by using 
"lsblk" and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" 
to create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w". check


Next format partition to ext4 filesystem:
 $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1 check

Next mount the filesystem:
 $ sudo mkdir /mnt/disktest check
 $ sudo mount /dev/sdX1 /mnt/disktest check

Next create reference 1GB file filled with dummy data:
 $ cd /mnt/disktest check
 $ sudo fallocate -l 1G ./reftestfile check
 $ sudo badblocks -w -s -t random ./reftestfile check

Now we can use script to create 1830 1GB files and check their checksum:
 $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to 
checksum of "reftestfile":

 $ md5sum -b ./reftestfile

Got a problem Alexander:
I had to put the script someplace else. So I put it in my private 
/home/gene/bin as disktest.txt with nano. couldn't find it.

But:
gene@coyote:/mnt/disktest$ sudo /home/gene/bin/disktest.txt
sudo: /home/gene/bin/disktest.txt: command not found
If you put that 'for' loop one-liner inside, I think you forgot to make 
"/home/gene/bin/disktest.txt" executable:

    $ chmod +x /home/gene/bin/disktest.txt


And:
gene@coyote:/mnt/disktest$ ls /home/gene/bin/disktest.txt
/home/gene/bin/disktest.txt
So I think I found the problem with my script, ancient eyeballs can't 
tell the diff between () and{} so I fixed that but it still won't run 
or be killed. I don't care how big you've made the t-bird font, by the 
time you've read 2 more msgs, its back to about 6 point text.  Grrr.


So I fired up a root session of htop, found about 8 copies of dd 
showing and started killing them but cannot kill the last 2 in the D 
state.


And cannot find .disktest.txt running in a root htop and the2 copy's 
of dd can't be killall'd.



It's not possible for me to know what went wrong.
Have you created "reftestfile" inside "/mnt/disktest" directory?
How many "testfile*" files, if any, were created on the filesystem 
mounted at "/mnt/disktest"?

Was there anything relevant in the syslog about "sdm" drive after the test?
If you'd followed my instructions step by step, you'd end up inside 
"/mnt/disktest" directory and for the last step all you had to do is 
copy and paste that one-liner 'for' loop into the command line.
It's a long line and it really meant to be copied and pasted not typed 
by hand, and also to give you the idea of the process, so you could 
adjust it if needed.
I've tested it again on my computer and it worked as expected, 
synchronously created "testfiles" inside current directory and 
calculated their hashes one by one.



--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: testing new sdm drive

[gene heskett]

On 2/8/24 07:22, Alexander V. Makartsev wrote:

On 08.02.2024 12:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0
Revision: 2.00
Compliance:   SPC-2
User Capacity:    2,097,152,000,000 bytes [2.09 TB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta

Cheers, Gene Heskett, CET.


Looks like a scam. Probably a reprogrammed controller to falsely report 
2TB of space to the system.


This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
     $ sudo gdisk /dev/sdX check

/!\  Make double sure you've selected the right device by using "lsblk" 
and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" to 
create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w". check


Next format partition to ext4 filesystem:
     $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1 check

Next mount the filesystem:
     $ sudo mkdir /mnt/disktest check
     $ sudo mount /dev/sdX1 /mnt/disktest check

Next create reference 1GB file filled with dummy data:
     $ cd /mnt/disktest check
     $ sudo fallocate -l 1G ./reftestfile check
     $ sudo badblocks -w -s -t random ./reftestfile check

Now we can use script to create 1830 1GB files and check their checksum:
     $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to checksum 
of "reftestfile":

     $ md5sum -b ./reftestfile

Got a problem Alexander:
I had to put the script someplace else. So I put it in my private 
/home/gene/bin as disktest.txt with nano. couldn't find it.

But:
gene@coyote:/mnt/disktest$ sudo /home/gene/bin/disktest.txt
sudo: /home/gene/bin/disktest.txt: command not found
And:
gene@coyote:/mnt/disktest$ ls /home/gene/bin/disktest.txt
/home/gene/bin/disktest.txt
So I think I found the problem with my script, ancient eyeballs can't 
tell the diff between () and{} so I fixed that but it still won't run or 
be killed. I don't care how big you've made the t-bird font, by the time 
you've read 2 more msgs, its back to about 6 point text.  Grrr.


So I fired up a root session of htop, found about 8 copies of dd showing 
and started killing them but cannot kill the last 2 in the D state.


And cannot find .disktest.txt running in a root htop and the2 copy's of 
dd can't be killall'd.



     3f2c5fa95492bfaa18f08c801037d80b *./reftestfile


Next?
     $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done

     3f2c5fa95492bfaa18f08c801037d80b *./testfile1
     3f2c5fa95492bfaa18f08c801037d80b *./testfile2
     ...
     3f2c5fa95492bfaa18f08c801037d80b *./testfile1830

Obviously, checksum for your "reftestfile" will be different from mine.
If 'for' loop fails at some point, you can count testfiles to see how 
many of them were actually written to disk.



--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[tomas]

On Fri, Feb 09, 2024 at 09:21:24AM -0500, Stefan Monnier wrote:
> >> So, if you want to use `badblocks`, you may want to do it on an
> >> encrypted partition (that covers the whole device) rather than on the
> >> raw device.
> > This is an interesting idea. I haven't wrapped my head around "what if
> > the controller maps several block addresses to the same physical block"?
> 
> I assume that's what those thingies do.  But disk encryption encrypts
> every block in a different way (otherwise, your encryption system is too
> poor and will leak information when comparing different blocks), so even
> if you write nothing but zeroes over your whole encrypted partition, the
> encryption will turn them into blocks that have all different contents.

Yes, but those device cheat, they do wear levelling and move (physical)
blocks around behind your back. If you write (logical) block N and read
it right away, chances are good that it comes out clean. But (logical)
block M (fr M << N) may just have been corrupted. That's why I think
you'll have to fill first, then check.

> This said, for the task at hand F3 seems like a simpler and more
> direct answer.

Possibly. I haven't read the man page yet.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: testing new sdm drive

[Max Nikulin]

On 09/02/2024 20:23, Dan Ritter wrote:

I would (I have, in the past) generate a non-random but mostly
incompressible large file


There are 2 kinds of random number generators:
- Cryptographic grade are intentionally hard to predict
- Pseudo-random

A pseudo-random generator of reasonable quality allows to get long 
enough non-repeating sequence. It can be reproduced if its initial state 
is saved. This property is used for Monte-Carlo simulations in physics, etc.


So you may save a hundred bytes and may check if several Tb generated 
from it is the same.


Is there a reason to avoid the f3 tool? I have tried it only on 32G USB 
and µSD cards, however I do not see a reason why I can not be used for a 
SSD.


As another test I would leave a suspicious drive for a month unpowered 
and check if data are not corrupted. I think, a scenario like

https://blog.gsmarena.com/how-do-you-spot-fake-chinese-usb-hard-drives-well-you-take-them-apart/
is a pessimistic one. A more realistic case is faulty chips with leaking 
memory cells that did not pass quality control.

Re: testing new sdm drive

[Stefan Monnier]

>> So, if you want to use `badblocks`, you may want to do it on an
>> encrypted partition (that covers the whole device) rather than on the
>> raw device.
> This is an interesting idea. I haven't wrapped my head around "what if
> the controller maps several block addresses to the same physical block"?

I assume that's what those thingies do.  But disk encryption encrypts
every block in a different way (otherwise, your encryption system is too
poor and will leak information when comparing different blocks), so even
if you write nothing but zeroes over your whole encrypted partition, the
encryption will turn them into blocks that have all different contents.

This said, for the task at hand F3 seems like a simpler and more
direct answer.


Stefan

Re: testing new sdm drive

[tomas]

On Fri, Feb 09, 2024 at 08:23:30AM -0500, Dan Ritter wrote:
> to...@tuxteam.de wrote: 
> > On Fri, Feb 09, 2024 at 07:50:18AM -0500, Stefan Monnier wrote:
> > > So, if you want to use `badblocks`, you may want to do it on an
> > > encrypted partition (that covers the whole device) rather than on the
> > > raw device.
> > 
> > This is an interesting idea. I haven't wrapped my head around "what if
> > the controller maps several block addresses to the same physical block"?
> > 
> > Perhaps you'd have to fill the disk and check afterwards?
> 
> Blocks are very likely to be 128KB, sometimes 64KB.
> 
> I would (I have, in the past) generate a non-random but mostly
> incompressible large file -- a compressed movie is pretty good for this -- 
> use md5sum to get its hash, and then write it under a variety of
> names until I fill the disk. 
> 
> Then read back each file and compare the md5sum of each file to
> the known value. They should be all the same.
> 
> I found a bad RAID controller this way.

What I'd do is encrypt the block number (in whichever form) padded
with zeros to block size with some symmetric scheme (e.g. AES) and
a constant symmetric key. That should be "random enough" and still
repeatable in the sense that, given the block number you know how
it is supposed to look like.

Plus, if you're lucky and have chosen the cipher judiciously, your
CPU might help you to make it fast.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: testing new sdm drive

[Dan Ritter]

to...@tuxteam.de wrote: 
> On Fri, Feb 09, 2024 at 07:50:18AM -0500, Stefan Monnier wrote:
> > So, if you want to use `badblocks`, you may want to do it on an
> > encrypted partition (that covers the whole device) rather than on the
> > raw device.
> 
> This is an interesting idea. I haven't wrapped my head around "what if
> the controller maps several block addresses to the same physical block"?
> 
> Perhaps you'd have to fill the disk and check afterwards?

Blocks are very likely to be 128KB, sometimes 64KB.

I would (I have, in the past) generate a non-random but mostly
incompressible large file -- a compressed movie is pretty good for this -- 
use md5sum to get its hash, and then write it under a variety of
names until I fill the disk. 

Then read back each file and compare the md5sum of each file to
the known value. They should be all the same.

I found a bad RAID controller this way.

-dsr-

Re: testing new sdm drive

[tomas]

On Fri, Feb 09, 2024 at 07:50:18AM -0500, Stefan Monnier wrote:
> > BTW2, there is a program for that, "badblocks", part of e2fsprograms, so
> > chances are it's installed. I'd look into that man page.
> 
> `badblocks` sadly writes the same pattern on every block, AFAIK, so if
> the drive just remaps new logical blocks to already used physical
> blocks, `badblocks` may be convinced that the drive works fine even when
> it doesn't.

Absolutely right. And most probably it checks a block right after writing,
and doesn't try to fill up the disk first.

> So, if you want to use `badblocks`, you may want to do it on an
> encrypted partition (that covers the whole device) rather than on the
> raw device.

This is an interesting idea. I haven't wrapped my head around "what if
the controller maps several block addresses to the same physical block"?

Perhaps you'd have to fill the disk and check afterwards?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: testing new sdm drive

[Stefan Monnier]

> BTW2, there is a program for that, "badblocks", part of e2fsprograms, so
> chances are it's installed. I'd look into that man page.

`badblocks` sadly writes the same pattern on every block, AFAIK, so if
the drive just remaps new logical blocks to already used physical
blocks, `badblocks` may be convinced that the drive works fine even when
it doesn't.

So, if you want to use `badblocks`, you may want to do it on an
encrypted partition (that covers the whole device) rather than on the
raw device.


Stefan

Re: testing new sdm drive

[gene heskett]

On 2/8/24 15:11, Alexander V. Makartsev wrote:

On 09.02.2024 00:23, gene heskett wrote:
Looks neat. Any chance this will crash my machine? I have other design 
work going on, and I'd hate to have to start from scratch.
Well, it will consume CPU cycles for sure, at least to calculate md5 
hashes and perform I/O on the target drive and RAM.
I don't think it could crash the system, but the load could be 
significant enough to disturb your work, so
if I was in your place I'd wait until the machine is free from any work 
or load and then test the new drive.


That is my intentions, but I'm in the middle of making a tronxy400-pro 
that has never worked so I using the frame to build a printer that 
works.  Doing essentially the same with an Ender 5 Plus. Including 
klipper, a bpi5-m5, the whole MaryAnn.  So OpenSCAD is busier than that 
famous cat on a tin roof.

--
With kindest regards, Alexander.

Take care yourself Alexander.


⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[gene heskett]

On 2/8/24 13:25, David Christensen wrote:

On 2/7/24 23:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0
Revision: 2.00
Compliance:   SPC-2
User Capacity:    2,097,152,000,000 bytes [2.09 TB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

 >> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta

Cheers, Gene Heskett, CET.



Please try again with the drive connected directly to a motherboard USB 
3.0 port.



That is where it still is, on a blue usb3.0 port on a 3 yo ASUS mobo.


I seem to recall that you have a lot of USB devices connected to your 
computer(s).  The Asus PRIME Z370-A II Series manual page ix states:


Intel ® Z370 Chipset
- 6 x USB 3.1 Gen 1 ports (4 ports @mid-board, 2 ports @back panel)
USB
- 6 x USB 2.0/1.1 ports (4 ports @mid-board, 2 ports @back panel)
Asmedia ® USB 3.1 Gen 2 controller
- 1 x USB 3.1 Gen 2 port @back panel (teal blue, Type-A)
- 1 x USB 3.1 Gen 2 port @back panel (USB Type CTM)


Page 1-16 states:

USB 3.1 Gen 1 connectors (20-1 pin U31G1_12; U31G1_34)

This connector allows you to connect a USB 3.1 Gen 1 module for 
additional USB 3.1 Gen 1 front or rear panel ports. With an installed 
USB 3.1 Gen 1 module, you can enjoy all the benefits of USB 3.1 Gen 
1including faster data transfer speeds of up to 5 Gb/s, faster charging 
time for USB-chargeable devices, optimized power efficiency, and 
backward compatibility with USB 2.0.


The USB 3.1 Gen 1 module is purchased separately.


Page 1-17 states:

USB 2.0 connectors (10-1 pin USB910; USB1112)

These connectors are for USB 2.0 ports. Connect the USB module cable to 
these connectors, then install the module to a slot opening at the back 
of the system chassis. This USB connector complies with USB 2.0 
specification that supports up to 480 Mb/s connection speed.


The USB 2.0 module is purchased separately.


STFW including asus.com, I am unable to find "USB 3.1 Gen 1 module" or 
"USB 2.0 module" (?).



Does your chassis have front panel USB 2.0 and/or USB 3.1 Gen 1 ports 
with cables and matching connectors?  Have you connected them to the 
motherboard headers?  Do they work?



Alternatively, if you have an available chassis expansion slot:

https://www.startech.com/en-us/cables/usbplate4


I am unable to find a similar part for the motherboard USB 3.1 Gen 1 
20-pin headers.  Perhaps a USB 3.0 will work (?):


https://www.amazon.com/RIITOP-Female-Connector-Adapter-Bracket/dp/B01KJPUI5W


Or, if you have an available motherboard PCIe slot:

https://www.startech.com/en-us/cards-adapters/usb-30/cards?filter_bustype=pci%2520express


David

.


Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[David Christensen]

On 2/8/24 12:36, Linux-Fan wrote:

Alexander V. Makartsev writes:

From here on I'd suggest trying the tools from package `f3`.



Thank you for the suggestion -- I was hoping somebody knew of a FOSS 
Debian package that can validate drive capacity:


https://packages.debian.org/bookworm/f3

https://oss.digirati.com.br/f3/

https://fight-flash-fraud.readthedocs.io/en/stable/


David

Re: testing new sdm drive

[David Christensen]

On 2/8/24 11:23, gene heskett wrote:

On 2/8/24 07:22, Alexander V. Makartsev wrote:

This is how I would test it.
...
Looks neat. Any chance this will crash my machine? I have other design 
work going on, and I'd hate to have to start from scratch.



Do not use a production computer for drive maintenance; especially not 
your primary workstation.  Use a spare computer.



I thought you were going to hook up all the new USB SSD's to a USB hub 
to a SBC, and turn it into a file server, backup server, or some such?



David

Re: testing new sdm drive

[tomas]

On Fri, Feb 09, 2024 at 01:11:05AM +0500, Alexander V. Makartsev wrote:
> On 09.02.2024 00:23, gene heskett wrote:
> > Looks neat. Any chance this will crash my machine? I have other design
> > work going on, and I'd hate to have to start from scratch.
> Well, it will consume CPU cycles for sure, at least to calculate md5 hashes
> and perform I/O on the target drive and RAM.

...unless the device under test starts misbehaving (what, after all, is
the thing we are after). Then, probably, all bets are off. If it "just"
starts reporting bad blocks or just returning corrupted data, I guess
the kernel will cope, but things are... complex ;-)

> I don't think it could crash the system, but the load could be significant
> enough to disturb your work, so
> if I was in your place I'd wait until the machine is free from any work or
> load and then test the new drive.

Sound wise, yes. Perhaps you have a spare raspi you can dedicate to this
boring task. Or an old laptop gathering dust.

BTW, if it was me, I'd skip the file system part and just dd checksummed
blocks to it (and read them back with dd), thus sparing a whole layer of
complexity and difficult to predict behaviour (caching, what not).

BTW2, there is a program for that, "badblocks", part of e2fsprograms, so
chances are it's installed. I'd look into that man page.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: testing new sdm drive

[Linux-Fan]

Alexander V. Makartsev writes:


On 08.02.2024 12:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local  
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke,  
http://www.smartmontools.org>www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0


[...]

Looks like a scam. Probably a reprogrammed controller to falsely report 2TB  
of space to the system.


I support this view :)


This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
    $ sudo gdisk /dev/sdX

/!\  Make double sure you've selected the right device by using "lsblk" and  
"blkid" utilities.  /!\
/!\    It could change from 'sdm' to another name  
after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" to create  
a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to device  
press "w".


Next format partition to ext4 filesystem:
    $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1

Next mount the filesystem:
    $ sudo mkdir /mnt/disktest
    $ sudo mount /dev/sdX1 /mnt/disktest

Next create reference 1GB file filled with dummy data:
    $ cd /mnt/disktest



From here on I'd suggest trying the tools from package `f3`.


After installing it, find the documentation under
/usr/share/doc/f3/README.rst.gz. Basic usage requires only two commands:

f3write .

Fills the drive until it is full (No Space Left on Device). Umount and re- 
mount it to ensure that data is actually written to the disk. Then switch  
back to /mnt/disktest and read it back using


f3read .

It should output a tabular summary about what could be read successfully and  
what couldn't.


As to whether this affects the stability of the running system: If the drive  
is fake (which I think is a real possibility) then it may as well cause  
hickups in the system. If the work you are doing on the machine is mission- 
critical, don't run tests with suspect hardware on it...


HTH
Linux-Fan

öö

[...]


pgpxY5QIR73gw.pgp
Description: PGP signature

Re: testing new sdm drive

[Alexander V. Makartsev]

On 09.02.2024 00:23, gene heskett wrote:
Looks neat. Any chance this will crash my machine? I have other design 
work going on, and I'd hate to have to start from scratch.
Well, it will consume CPU cycles for sure, at least to calculate md5 
hashes and perform I/O on the target drive and RAM.
I don't think it could crash the system, but the load could be 
significant enough to disturb your work, so
if I was in your place I'd wait until the machine is free from any work 
or load and then test the new drive.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: testing new sdm drive

[gene heskett]

On 2/8/24 07:22, Alexander V. Makartsev wrote:

On 08.02.2024 12:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0
Revision: 2.00
Compliance:   SPC-2
User Capacity:    2,097,152,000,000 bytes [2.09 TB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta

Cheers, Gene Heskett, CET.


Looks like a scam. Probably a reprogrammed controller to falsely report 
2TB of space to the system.


This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
     $ sudo gdisk /dev/sdX

/!\  Make double sure you've selected the right device by using "lsblk" 
and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" to 
create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w".


Next format partition to ext4 filesystem:
     $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1

Next mount the filesystem:
     $ sudo mkdir /mnt/disktest
     $ sudo mount /dev/sdX1 /mnt/disktest

Next create reference 1GB file filled with dummy data:
     $ cd /mnt/disktest
     $ sudo fallocate -l 1G ./reftestfile
     $ sudo badblocks -w -s -t random ./reftestfile

Now we can use script to create 1830 1GB files and check their checksum:
     $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to checksum 
of "reftestfile":

     $ md5sum -b ./reftestfile
     3f2c5fa95492bfaa18f08c801037d80b *./reftestfile

     $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done

     3f2c5fa95492bfaa18f08c801037d80b *./testfile1
     3f2c5fa95492bfaa18f08c801037d80b *./testfile2
     ...
     3f2c5fa95492bfaa18f08c801037d80b *./testfile1830

Obviously, checksum for your "reftestfile" will be different from mine.
If 'for' loop fails at some point, you can count testfiles to see how 
many of them were actually written to disk.


Looks neat. Any chance this will crash my machine? I have other design 
work going on, and I'd hate to have to start from scratch.


--
With kindest regards, Alexander.

Thank you Alexander.

Cheers, Gene Heskett, CET.
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: testing new sdm drive

[Dan Ritter]

David Christensen wrote: 
> 
> Page 1-16 states:
> 
> USB 3.1 Gen 1 connectors (20-1 pin U31G1_12; U31G1_34)
> 
> This connector allows you to connect a USB 3.1 Gen 1 module for additional
> USB 3.1 Gen 1 front or rear panel ports. With an installed USB 3.1 Gen 1
> module, you can enjoy all the benefits of USB 3.1 Gen 1including faster data
> transfer speeds of up to 5 Gb/s, faster charging time for USB-chargeable
> devices, optimized power efficiency, and backward compatibility with USB
> 2.0.
> 
> The USB 3.1 Gen 1 module is purchased separately.
> 
> 
> STFW including asus.com, I am unable to find "USB 3.1 Gen 1 module" or "USB
> 2.0 module" (?).

USB 3.0 Gen 1 is a rename of USB 3.0.

2x Type A from standard motherboard header:
https://www.newegg.com/p/181-0783-00017?Item=9SIAPY9F266548

-dsr-

Re: testing new sdm drive

[David Christensen]

On 2/8/24 10:24, David Christensen wrote:

On 2/7/24 23:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
...
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

 >> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

...
Please try again with the drive connected directly to a motherboard USB 
3.0 port.



Error:  The motherboard has no USB 3.0 ports.


Correction:  Please try connecting the drive to each and every 
motherboard USB port to see if and which ports work with the drive and 
smartctl(8).



David

Re: testing new sdm drive

[David Christensen]

On 2/7/24 23:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)

Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0
Revision: 2.00
Compliance:   SPC-2
User Capacity:    2,097,152,000,000 bytes [2.09 TB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
 >> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more 
'-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta

Cheers, Gene Heskett, CET.



Please try again with the drive connected directly to a motherboard USB 
3.0 port.



I seem to recall that you have a lot of USB devices connected to your 
computer(s).  The Asus PRIME Z370-A II Series manual page ix states:


Intel ® Z370 Chipset
- 6 x USB 3.1 Gen 1 ports (4 ports @mid-board, 2 ports @back panel)
USB
- 6 x USB 2.0/1.1 ports (4 ports @mid-board, 2 ports @back panel)
Asmedia ® USB 3.1 Gen 2 controller
- 1 x USB 3.1 Gen 2 port @back panel (teal blue, Type-A)
- 1 x USB 3.1 Gen 2 port @back panel (USB Type CTM)


Page 1-16 states:

USB 3.1 Gen 1 connectors (20-1 pin U31G1_12; U31G1_34)

This connector allows you to connect a USB 3.1 Gen 1 module for 
additional USB 3.1 Gen 1 front or rear panel ports. With an installed 
USB 3.1 Gen 1 module, you can enjoy all the benefits of USB 3.1 Gen 
1including faster data transfer speeds of up to 5 Gb/s, faster charging 
time for USB-chargeable devices, optimized power efficiency, and 
backward compatibility with USB 2.0.


The USB 3.1 Gen 1 module is purchased separately.


Page 1-17 states:

USB 2.0 connectors (10-1 pin USB910; USB1112)

These connectors are for USB 2.0 ports. Connect the USB module cable to 
these connectors, then install the module to a slot opening at the back 
of the system chassis. This USB connector complies with USB 2.0 
specification that supports up to 480 Mb/s connection speed.


The USB 2.0 module is purchased separately.


STFW including asus.com, I am unable to find "USB 3.1 Gen 1 module" or 
"USB 2.0 module" (?).



Does your chassis have front panel USB 2.0 and/or USB 3.1 Gen 1 ports 
with cables and matching connectors?  Have you connected them to the 
motherboard headers?  Do they work?



Alternatively, if you have an available chassis expansion slot:

https://www.startech.com/en-us/cables/usbplate4


I am unable to find a similar part for the motherboard USB 3.1 Gen 1 
20-pin headers.  Perhaps a USB 3.0 will work (?):


https://www.amazon.com/RIITOP-Female-Connector-Adapter-Bracket/dp/B01KJPUI5W


Or, if you have an available motherboard PCIe slot:

https://www.startech.com/en-us/cards-adapters/usb-30/cards?filter_bustype=pci%2520express


David

Re: testing new sdm drive

[Alexander V. Makartsev]

On 08.02.2024 12:14, gene heskett wrote:

gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
www.smartmontools.org


=== START OF INFORMATION SECTION ===
Vendor:
Product:  SSD 3.0
Revision: 2.00
Compliance:   SPC-2
User Capacity:    2,097,152,000,000 bytes [2.09 TB]
Logical block size:   512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 
bd_len=0

>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or 
more '-T permissive' options.

gene@coyote:/etc$

And then again, it worked, sorta

Cheers, Gene Heskett, CET.


Looks like a scam. Probably a reprogrammed controller to falsely report 
2TB of space to the system.


This is how I would test it.
First create a new GPT partition table and a new 2TB partition:
    $ sudo gdisk /dev/sdX

/!\  Make double sure you've selected the right device by using "lsblk" 
and "blkid" utilities.  /!\
/!\    It could change from 'sdm' to another 
name after reboot.      /!\


At gdisk prompt press "o" to create a new GPT table, next press "n" to 
create a new partition, accept default values by pressing "enter".
To verify setup press "p", to accept configuration and write it to 
device press "w".


Next format partition to ext4 filesystem:
    $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1

Next mount the filesystem:
    $ sudo mkdir /mnt/disktest
    $ sudo mount /dev/sdX1 /mnt/disktest

Next create reference 1GB file filled with dummy data:
    $ cd /mnt/disktest
    $ sudo fallocate -l 1G ./reftestfile
    $ sudo badblocks -w -s -t random ./reftestfile

Now we can use script to create 1830 1GB files and check their checksum:
    $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done


This procedure will take a very long time to complete. "md5sum" will 
output the checksum for each file and they should be equal to checksum 
of "reftestfile":

    $ md5sum -b ./reftestfile
    3f2c5fa95492bfaa18f08c801037d80b *./reftestfile

    $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done

    3f2c5fa95492bfaa18f08c801037d80b *./testfile1
    3f2c5fa95492bfaa18f08c801037d80b *./testfile2
    ...
    3f2c5fa95492bfaa18f08c801037d80b *./testfile1830

Obviously, checksum for your "reftestfile" will be different from mine.
If 'for' loop fails at some point, you can count testfiles to see how 
many of them were actually written to disk.



--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄