[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: smartctl cannot access my storage, need syntax help

On 1/15/24 18:41, gene heskett wrote:

On 1/15/24 17:58, gene heskett wrote:

On 1/15/24 14:55, David Wright wrote:

On Mon 15 Jan 2024 at 08:39:37 (-0500), gene heskett wrote:

On 1/14/24 20:19, gene heskett wrote:

On 1/14/24 19:48, David Wright wrote:

On Sun 14 Jan 2024 at 14:48:49 (-0500), gene heskett wrote:

On 1/14/24 07:42, David Christensen wrote:



I am confused -- do you have 4 or 5 Gigastone 2 TB SSD?


5,  ordered in 2 separate orders.


   > So that one could be formatted ext4 and serve as a
backup of the raid10.

What I am trying to do now, but cannot if it is plugged into a
motherboard port, hence the repeat of thnis exercise on the 2nd sata
card.


   > how do I make an image of that
   > raid10  to /dev/sde and get every byte?  That
seems like the first step
   > to me.
This I am still trying to do, the first pass copied all 350G of /home but went to the wrong drive, and I had mounted the drive by its label. 
It is now /dev/sdh and all labels above it are now wrong. Crazy.
These SSD's all have an OTP serial number. I am tempted to use that
serial number as a label _I_ can control. And according to gparted,
labels do not survive being incorporated into a raid as the raid is
all labeled with hostname : partition number. So there really is no
way in linux to define a drive that is that drive forever. Unreal...


Interesting to see in how many differents ways you can use the
term "label". BTW I have no idea what an "OTP serial number" is.


OTP=One Time Pad, never to be used again.


I too can lookup acronyms with ease. I asked about "OTP serial number",
not "OTP" serial number.


I moved the data cable to where I knew I could find it again, as one
of 5 drives attached to the 16 port card,


No idea what that means.


and on reboot it shows up in
an lsblk list as:
root@coyote:~# lsblk


[ … table showing five Samsungs, five Gigastones, and two
     other items, perhaps printer (confirmed later) and camera … ]


Now confirmed by looking at all 5 with gparted, there are only 3
unique serial numbers:


I don't see any parted output.

cuz it doesn't want to be copy/pasted.



root@coyote:~# ls /dev/disk/by-id
ls -1   would at least sort out this mess, but more useful would be ls -l or  for j in /dev/disk/by-id/* ; do printf '%s\t%s\n' "$(realpath "$j")" "$j" ; done 
as you could then see what the symlinks point to, which after all
is their raison d'être.

Thanks for that composition: but it will be word wrapped:
root@coyote:~# for j in /dev/disk/by-id/* ; do printf '%s\t%s\n' "$(realpath "$j")" "$j" ; done 
/dev/sr0        /dev/disk/by-id/ata-ATAPI_iHAS424_B_3524253_327133504865
/dev/sdi        /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146
/dev/sdj1       /dev/disk/by-id/ata-Gigastone_SSD_GST02TBG221146-part1
/dev/sdh        /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102
/dev/sdh1       /dev/disk/by-id/ata-Gigastone_SSD_GSTD02TB230102-part1
/dev/sdk        /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206
/dev/sdk1       /dev/disk/by-id/ata-Gigastone_SSD_GSTG02TB230206-part1
/dev/sdf /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T /dev/sdf1 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part1 /dev/sdf2 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part2 /dev/sdf3 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302498T-part3 /dev/sde /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E /dev/sde1 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part1 /dev/sde2 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part2 /dev/sde3 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302502E-part3 /dev/sdd /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V /dev/sdd1 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part1 /dev/sdd2 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part2 /dev/sdd3 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302507V-part3 /dev/sdg /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W /dev/sdg1 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part1 /dev/sdg2 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part2 /dev/sdg3 /dev/disk/by-id/ata-Samsung_SSD_870_EVO_1TB_S626NF0R302509W-part3 /dev/sda /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V /dev/sda1 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part1 /dev/sda2 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part2 /dev/sda3 /dev/disk/by-id/ata-Samsung_SSD_870_QVO_1TB_S5RRNF0T201730V-part3 
/dev/md0        /dev/disk/by-id/md-name-coyote:0
/dev/md0p1      /dev/disk/by-id/md-name-coyote:0-part1
/dev/md2        /dev/disk/by-id/md-name-coyote:2
/dev/md1        /dev/disk/by-id/md-name-_none_:1
/dev/md0 /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb /dev/md0p1 /dev/disk/by-id/md-uuid-3d5a3621:c0e32c8a:e3f7ebb3:318edbfb-part1 /dev/md1 /dev/disk/by-id/md-uuid-57a88605:27f5a773:5be347c1:7c5e7342 /dev/md2 /dev/disk/by-id/md-uuid-bb6e03ce:19d290c8:5171004f:0127a392 
/dev/sdc        /dev/disk/by-id/usb-Brother_MFC-J6920DW_BROG5F229909-0:0
/dev/sdb /dev/disk/by-id/usb-USB_Mass_Storage_Device_816820130806-0:0
/dev/sdf        /dev/disk/by-id/wwn-0x5002538f413394a5
/dev/sdf1       /dev/disk/by-id/wwn-0x5002538f413394a5-part1
/dev/sdf2       /dev/disk/by-id/wwn-0x5002538f413394a5-part2
/dev/sdf3       /dev/disk/by-id/wwn-0x5002538f413394a5-part3
/dev/sde        /dev/disk/by-id/wwn-0x5002538f413394a9
/dev/sde1       /dev/disk/by-id/wwn-0x5002538f413394a9-part1
/dev/sde2       /dev/disk/by-id/wwn-0x5002538f413394a9-part2
/dev/sde3       /dev/disk/by-id/wwn-0x5002538f413394a9-part3
/dev/sdd        /dev/disk/by-id/wwn-0x5002538f413394ae
/dev/sdd1       /dev/disk/by-id/wwn-0x5002538f413394ae-part1
/dev/sdd2       /dev/disk/by-id/wwn-0x5002538f413394ae-part2
/dev/sdd3       /dev/disk/by-id/wwn-0x5002538f413394ae-part3
/dev/sdg        /dev/disk/by-id/wwn-0x5002538f413394b0
/dev/sdg1       /dev/disk/by-id/wwn-0x5002538f413394b0-part1
/dev/sdg2       /dev/disk/by-id/wwn-0x5002538f413394b0-part2
/dev/sdg3       /dev/disk/by-id/wwn-0x5002538f413394b0-part3
/dev/sda        /dev/disk/by-id/wwn-0x5002538f42205e8e
/dev/sda1       /dev/disk/by-id/wwn-0x5002538f42205e8e-part1
/dev/sda2       /dev/disk/by-id/wwn-0x5002538f42205e8e-part2
/dev/sda3       /dev/disk/by-id/wwn-0x5002538f42205e8e-part3
root@coyote:~#
but like I wrote, 2 pairs with identical "serial numbers", so the assunption is that the last one overwrites the first on by udev, when IMO it should be yelling about the duplicats. 

Extracting:


ata-Gigastone_SSD_GST02TBG221146
ata-Gigastone_SSD_GSTD02TB230102
ata-Gigastone_SSD_GSTG02TB230206


these devices appear to have normal serial numbers. Do they bear
any other indication, like engravings or stickers? If not, I would,
in turn, plug each one in, read the serial number from its symlink,
and write on it with a marker. While doing that, you could also
run smartctl.
There is a sticker on the bottom containing the numbers you see above, and a (upc?) bar code I don't have a reader for. 
only 3 unique serial numbers!!!!!!
udev when finding that situation should scream from the rooftops!!
not silently overwrite an entry in the by-id that its already made.


If you say so. I never had any problem with udev when I had
three identical USB sticks with the "serial" number
ID_SERIAL=SMI_USB_DISK-0:0
I scratched distinguishing letter on them, and watched xconsole for
the drive letter whenever I plugged one in. At 8GB a piece, the
largest I had at the time, they were very useful. And they didn't
cost me a penny as they were giveaways.


HTH do I fix that?
can tune2fs edit a serial number? no.
can the UUID be rendered read-only, no.
gparted and similar can change the UUID by a click of the mouse.
I'm officially screwed and I have had them too long to return them now.


You need to find out, in turn, which ones work, and that goes for
both the SSDs and wherever you plug them in. You can make little
progress at all without distinguishing them, as you have already
shown by copying data to who knows where.
Which occurred before I knew about the dups. Now you seem intent on calling me a liar, which I do not intentionally do.  I have now LABELed the drives but the only way I can prove it to you ts seems would be to take screen snapshots x5 of them, and one of those would be too big for the server.
Now, I have spent since around 08:30 my time this morning trying to backup this raid with around 350G of data on it, to one of those 2T gigastones but have lost the whole system because (apparently) rsync has a huge memory leak, the system is fine, until I start as root 

"rsync -av --bwlimit=3m --fsync /home/ /mnt/homevol"
which is where /dev/sdh1 is mounted. watch the system with htop, memory bar goes to full scale in tan, in 10 to 15 minutes and into swap 500 kilobytes in another 5 if OOM hasn't killed htop, the OOM daemon starts killing things, and is not the least fussy what.
I have tried it without the --bwlimit and --fsync but that just bombs the system faster. I thought I was overpower the write speed of the drive but slowing it to garden slug speeds still eats memory and the system gets killed. 38G of 350G is as far as I'm managed to get copied from 08:30 to 17:35. If that commandline above it correct, then as AFAIAC rsync is busted. The memory gauge bar is in 3 colors, green at the left is I prsume allocated mamory, next is red (cache maybe) and then tan or orange. The man page does not define what color signifies which but run rsync, it runs to the right end of the bar in orange/tan, then into swap and the system slowly dies.
I'm not a great user of rsync, use mc more often than not. I just have seen it take up from where the reset or power switch was used to reboot cuz the control of the system had been killed.  So the command line above might be the problem.  You tell me, please. 


That could even explain why my first run of rsync worked fine but went
to a drive that was NOT mounted.  And it was mounted by LABEL= The
only one of those 5 SSD's I had labeled at that time.


You haven't shown any evidence of such LABELling, and most of your
anecdotal narratives don't give much confidence for us to really
know what was actually done. But to be fair, anything could
happen if the hardware is not working properly.
I give up, lets see if a gparted screenshot comes thru. there was one attached when I hit send. 


Cheers,
David.



whoppie-ding, it worked. call me a liar again.

.


Cheers, Gene Heskett.


Cheers, Gene Heskett.


Cheers, Gene Heskett.
--
"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
Reply to: