Enterprise SAS SSD - Cannot Wipe

I have a pile of 2.5" SAS SSD I took out of a flash array from an old storage unit. The storage (Tegile) was encrypted and empty on decomm. There is no data on there of use.

I want to reuse them in some Dell 620 Servers we had laying around, but when I install the SSD the Dell says the disks are “Foreign” and refuse to do anything with them. No options are available. Done the usual reset of the PERC and imported the disk settings in accordance with the Dell Support site instructions, but nothing changes and no options appear. It looks like there is some sort of security block on the drives themselves stopping me from doing anything. Tried a few and they all act the same way.

I bought an SAS USB drive caddy for my Windows 10 workstation to wipe the drives directly. DiskPart and two hard drive utilities cannot clear / wipe or format the drive without throwing some sort of error. They see them, they just can’t interact with them in any way.

Windows Disk Management sees the drive as Unknown, but when I go to initialize the drive (both MBR and GPT) it say’s it can’t due to an I/O error.

Anybody run into this before? Need a way to force a wipe or format of these drives.

iDrac

Windows Disk Management
image

boot from linux, format sectors to 512 bytes, look on this forum for 520> 512byte instructions, that should work from a live linux iso

1 Like

I had an ssd that failed, which put it into a read-only mode which gave similar errors. Only mentioning this as something to keep in mind. Not sure this sort of fail-safe mechanism is used for SAS SSDs though.

Cheers @Antonius I think @wendell was on the money, but am working remotely today. Won’t be able to check the 520 > 512 until later in the week. It’s a good thing, as I have two dozen of the SSD I can hopefully fix and reuse with his method. I’ll report back when I know more.

Accessing the SSD via a USB SAS drive caddy running Linux Mint Live CD. GParted does not see it at all.

isblk (Edited, obviously)
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sdh 8:112 0 465.8G 0 disk

mint@mint:~$ sudo sg_scan -i (edited)
/dev/sg7: scsi8 channel=0 id=0 lun=0 [em]
Generic External 0157 [rmb=0 cmdq=0 pqual=0 pdev=0x0]

Read @wendell article here: Reformat 520 to 512
From what I see here, the size of the drive is already 512:

mint@mint:~$ sudo sg_readcap -v -l /dev/sg7
read capacity(16) cdb: [9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00]
Read Capacity results:
Protection: prot_en=0, p_type=0, p_i_exponent=0
Logical block provisioning: lbpme=0, lbprz=0
Last LBA=976773167 (0x3a38602f), Number of logical blocks=976773168
Logical block length=512 bytes
Logical blocks per physical block exponent=0
Lowest aligned LBA=0

mint@mint:~$ sudo smartctl -i /dev/sg7
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.0-41-generic] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model: HGST HUSMR1650ASS201
Serial Number: 0QW5DPXA
Add. Product Id: 13FD6710
Firmware Version: 1.5301
User Capacity: 500,107,862,016 bytes [500 GB]
Sector Size: 512 bytes logical/physical
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ATA8-ACS T13/1699-D revision 3c
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Fri Mar 1 14:44:02 2024 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Hence:
Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB

mint@mint:~$ sudo sg_format -v --format --size=512 /dev/sdh
Generic External 0157 peripheral_type: disk [0x0]
PROTECT=1
<< supports protection information>>
Unit serial number: 0QW5DPXA
LU name: 5000cca04e42343f
mode sense(10) cdb: [5a 00 01 00 00 00 00 00 fc 00]
mode sense(10):
Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid field in cdb
bad field in MODE SENSE (10) [mode_page 1 not supported?]

(Also tried:
sudo sg_format -S -v --format --size=512 /dev/sdh
sudo sg_format -S -v --format --size=520 /dev/sdh
to same result)

Finally, found some SAS drives could be wiped with SeaTools for Linux, installed the latest and it refuses to run any wipe or erase function. Just says “Failed to start” on any function.

Spent a bit more time on this.

mint@mint:~$ sudo sg_sanitize -B -v /dev/sdh
    Generic   External          0157   peripheral_type: disk [0x0]
      PROTECT=1
      << supports protection information>>
      Unit serial number: 0QW5DPXA            
      LU name: 5000cca04e42343f

A SANITIZE will commence in 15 seconds
    ALL data on /dev/sdh will be DESTROYED
        Press control-C to abort

A SANITIZE will commence in 10 seconds
    ALL data on /dev/sdh will be DESTROYED
        Press control-C to abort

A SANITIZE will commence in 5 seconds
    ALL data on /dev/sdh will be DESTROYED
        Press control-C to abort
Sanitize:
Fixed format, current; Sense key: Illegal Request
Additional sense: Invalid command operation code
Sanitize failed: Illegal request, Invalid opcode, type: sense key + asc,ascq

mint@mint:~$ sudo sg_sanitize --overwrite --zero /dev/sdh
    Generic   External          0157   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: 0QW5DPXA            
      LU name: 5000cca04e42343f

A SANITIZE will commence in 15 seconds
    ALL data on /dev/sdh will be DESTROYED
        Press control-C to abort

A SANITIZE will commence in 10 seconds
    ALL data on /dev/sdh will be DESTROYED
        Press control-C to abort

A SANITIZE will commence in 5 seconds
    ALL data on /dev/sdh will be DESTROYED
        Press control-C to abort
Sanitize failed: Illegal request, Invalid opcode
sg_sanitize failed: Illegal request, Invalid opcode

Found this article: https://community.spiceworks.com/t/utility-for-unlocking-hgst-sed-disk-drives-with-msid/761122/3

Tried it through the controller and get this:

Am sure it can be done through sg_utils. Just need the right combo of commands.

Does the H330 let you “cleanly” pass thorough the disk to linux? If not that might be a block to executing sg_utils. it makes sense that a USB adapter might not expose the drive to lower level commands.

@twin_savage I removed the drives and put them in a SAS USB3 caddy. So I have direct drive access with a Linux live CD. Once I get them formatted I can reinstall them and use them in the array.

I haven’t yet used a USB-SAS bridge, but back in the day most USB-SATA bridges couldn’t pass low level commands (like a firmware update) to the disks attached to them.
It’s possible something similar could happen with the SAS-USB bridge?

Not to derail the conversation, but what chipset does your SAS USB3 caddy use? I’m curious because these seem to be new.

Here is the link I used.

It has full access as far as I can see. The commands are working, they are hitting the security block on the drive itself.

https://www.amazon.com/dp/B0CL9HKBBK

So coming close to quitting on this. I contacted the vendor of the storage company and they want ungodly amounts of money to put a support contract in place with no guarantees. Not happening.

WD is saying the drives are OEM and their firmware isn’t compatible. According to them, there are no HGST specific utilities (despite being listed in their web pages) and to use their WD Dashboard software, which gives me no options to change anything or update firmware. I finally got sedutils to work and they are still blocked when using the PSID reset method.

Again, there is nothing on these drives I need so I’m happy to experiment as needed, but I’m running out of (reasonable) options.

Thanks all.

$ sudo ./sedutil-cli --scan
Scanning for Opal compliant disks
/dev/nvme0 No  PCIe SSD                                 EIFM51.1
/dev/nvme1 No  Sabrent Rocket Q4                        RKT40Q.1
/dev/nvme2 No  PCIe SSD                                 EIFM31.4
/dev/sda    2  Samsung SSD 870 EVO 2TB                  SVT02B6Q
/dev/sdb    2  Samsung SSD 870 EVO 2TB                  SVT02B6Q
/dev/sdc   No  USB Flash Drive  2.00
/dev/sdd   No   
/dev/sde   No  HGST    HUSMR1650ASS201                  1.5301  
No more disks present ending scan
$ sudo hdparm -I /dev/sde

/dev/sde:

ATA device, with non-removable media
	Model Number:       HGST    HUSMR1650ASS201                 
	Serial Number:      0QW5DPXA            
	Firmware Revision:  1.5301  
	Media Serial Num:   0QW5DPXA            
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
	Used: ATA-8-ACS revision 3c 
	Supported: 8 7 6 5 
Configuration:
	Logical		max	current
	cylinders	16383	0
	heads		16	0
	sectors/track	63	0
	--
	LBA    user addressable sectors:   268435455
	LBA48  user addressable sectors:   976773168
READ_LOG_EXT(0,0) failed: Input/output error
	Logical  Sector size:                   512 bytes
	Physical Sector size:                   512 bytes
	Logical Sector-0 offset:                  0 bytes
	device size with M = 1024*1024:      476940 MBytes
	device size with M = 1000*1000:      500107 MBytes (500 GB)
	cache/buffer size  = unknown
Capabilities:
	LBA, IORDY(can be disabled)
	Standby timer values: spec'd by Standard, with device specific minimum
	R/W multiple sector transfer: Max = 1	Current = 1
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	   *	48-bit Address feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Gen3 signaling speed (6.0Gb/s)
	   *	Software settings preservation
Checksum: correct
$ sudo ./sedutil-cli -vvvvv --yesIreallywanttoERASEALLmydatausingthePSID NXZE4ADWW0M6VSKM4WZE /dev/sde > revert.log
Log level set to DBG4
sedutil version : 1.20.0
Creating  DtaResponse()
Creating  DtaResponse()
DtaDevOS::init /dev/sde
Creating DtaDevLinuxSata::DtaDev() /dev/sde
Entering DtaDevLinuxSata::identify()
Entering DtaDev::discovery0()
Entering DtaDevLinuxSata::sendCmd
Send D0 request to device failed 255
Entering DtaDev::isPresent() 1
Entering DtaDev::isAnySSC 0
Invalid or unsupported disk /dev/sde
Destroying DtaDevOS
Destroying DtaDevLinuxSata
Destroying DtaResponse

I had a very similar situation to you where I pulled some SSDs from a Tegile. Like yours they are HGST but different model numbers. Here are my lessons learned.

Once a pool is created on the drives within the Tegile OS they are encrypted at locked. Literally nothing I did would unlock them even with the PSID. I was lucky enough to still have the Tegile and was able to boot back into Intelliflash where I was able to destroy the LUNs, projects, and pool. Once that was accomplished I was able secure erase them from the array GUI.

That “fixed” most of the drives however there were several that I was getting weird issues similar to what you are seeing with yours. They are not recognized with sedutil, sg_sanitize wouldn’t work, and smartctl couldn’t see all of the SMART data. I eventually figured out that these drives had SCSI reservations on them and for what ever reason wasn’t cleared when doing the secure erase from within the Tegile GUI.

From limited understanding depending what type of reservation it is any other host except for the host that created the reservation is unable to use the disk. Mine had exclusive write reservations which made them essentially read only. After removing the reservation all was well and the drives were able to be formatted and used normally.

These are the commands that I ran to remove the SCSI reservations from mine. The first command checks for reservations. The second registered a new reservation tied to the host that the drive is currently in. The third command removes the reservation created in step 2 and for reason not known to me also clears the persistent reservation from the Tegile as well.

sg_persist --in -s -d /dev/da0
sg_persist --out --register --param-sark=0xDEADBEEF /dev/da0
sg_persist --out --clear --param-rk=0xdeadbeef /dev/da0