Ultrastar DC SS200 SAS SSDs encrypted (TCG Enterprise?) with SPC-3 PR

Koop · May 14, 2024

Hello STH friends!

I've acquired a few Western Digital branded Ultrastar DC SS200 SAS SSDs. I've got them in a supermicro chassis in a SAS2 backplane connected to a AOC-S3008L-L8e updated and flashed into IT mode. Just want to provide some context in case this made any difference.

I'm not sure what system these drives came out of but I do have the drive sleds. It's not from a system I am familiar with.

On each drive:

P/N: 0TS1401
Model: SDLL1CLR-020T-CDA1
FW: X150

Each also has a PSID, WWN, date, etc. can provide pictures if needed.

I've loaded these drives into CentOS, Windows, and TrueNAS just to see what I would get. Basically in all three systems I'm unable to online, access, format, or do anything with the disks. TrueNAS has spit out a "Access denied - no access rights" error. Windows wouldn't let me online any disks. Couldn't format the drives anywhere. Here's what I'm seeing:

Code:

root@truenas[/]# sg_readcap -l /dev/sdc
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=1, lbprz=1
   Last LBA=3750748847 (0xdf8fe2af), Number of logical blocks=3750748848
   Logical block length=512 bytes
   Logical blocks per physical block exponent=3 [so physical block length=4096 bytes]
   Lowest aligned LBA=0
Hence:
   Device size: 1920383410176 bytes, 1831420.3 MiB, 1920.38 GB

Code:

root@truenas[/]# sg_format -v /dev/sdc
    HGST      SDLL1CLR020TCDA1  X150   peripheral_type: disk [0x0]
      PROTECT=1

Code:

root@truenas[/]# smartctl -a /dev/sdc
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.6.20-production+truenas] (local build)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HGST
Product:              SDLL1CLR020TCDA1
Revision:             X150
Compliance:           SPC-4
User Capacity:        1,920,383,410,176 bytes [1.92 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
LU is resource provisioned, LBPRZ=1
Rotation Rate:        Solid State Device
Form Factor:          2.5 inches
Logical Unit id:      0x500117310176cc00
Serial number:        [redacted]
Device type:          disk
Transport protocol:   SAS (SPL-4)
Local Time is:        Mon May 13 19:16:23 2024 PDT
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Percentage used endurance indicator: 2%
Grown defects during certification = 0
Total blocks reassigned during format = 0
Total new blocks reassigned = 0
Power on minutes since format = 1814013
Current Drive Temperature:     45 C
Drive Trip Temperature:        70 C

Accumulated power on time, hours:minutes 30298:06
Manufactured in week 09 of year 2018
Specified cycle count over device lifetime:  0
Accumulated start-stop cycles:  1149
Elements in grown defect list: 0

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0        0         0         0          0     807040.315           0
write:         0        0         0         0          0      82731.201           0

Non-medium error count:      311

No Self-tests have been logged

root@truenas[/]# sg_format -v --format --size=512 /dev/sdc
HGST SDLL1CLR020TCDA1 X150 peripheral_type: disk [0x0]
PROTECT=1
<< supports protection information>>
Unit serial number: [redacted]
LU name: 500117310176cc00
mode sense(10) cdb: [5a 00 01 00 00 00 00 00 fc 00]
Mode Sense (block descriptor) data, prior to changes:
Number of blocks=3750748848 [0xdf8fe2b0]
Block size=512 [0x200]

A FORMAT UNIT will commence in 15 seconds
ALL data on /dev/sdc will be DESTROYED
Press control-C to abort

A FORMAT UNIT will commence in 10 seconds
ALL data on /dev/sdc will be DESTROYED
Press control-C to abort

A FORMAT UNIT will commence in 5 seconds
ALL data on /dev/sdc will be DESTROYED
Press control-C to abort

Format unit cdb: [04 18 00 00 00 00]
Format unit command: Reservation conflict, type: SCSI status
FORMAT UNIT failed

Code:

root@truenas[/]# sg_sanitize --overwrite --zero /dev/sdc

    HGST      SDLL1CLR020TCDA1  X150   peripheral_type: disk [0x0]

      << supports protection information>>

      Unit serial number: [blah blah blah]


A SANITIZE will commence in 15 seconds

    ALL data on /dev/sdc will be DESTROYED

        Press control-C to abort


A SANITIZE will commence in 10 seconds

    ALL data on /dev/sdc will be DESTROYED

        Press control-C to abort


A SANITIZE will commence in 5 seconds

    ALL data on /dev/sdc will be DESTROYED

        Press control-C to abort

Sanitize failed: Reservation conflict

sg_sanitize failed: Reservation conflict

I tried to do the uhh erasemydata thing using the PSID and that too did not work.

Any ideas on what I should try? I'm not too familiar with trying to wipe drives like this so guidance is appreciated. Thank you!

NablaSquaredG · May 14, 2024

Koop said:
Any ideas on what I should try? I'm not too familiar with trying to wipe drives like this so guidance is appreciated. Thank you!

Have you tried sg_sanitize --crypto /dev/sd[x]?

Koop · May 14, 2024

NablaSquaredG said:
Have you tried sg_sanitize --crypto /dev/sd[x]?

I did, here's what that looked like:

Code:

root@truenas[/]# sg_sanitize --crypto /dev/sdb
    HGST      SDLL1CLR020TCDA1  X150   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: blah blah blah
      LU name: 500117310176cc00

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

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

A SANITIZE will commence in 5 seconds
    ALL data on /dev/sdb will be DESTROYED
        Press control-C to abort
Sanitize failed: Reservation conflict
sg_sanitize failed: Reservation conflict

NablaSquaredG · May 14, 2024

Koop said:
Sanitize failed: Reservation conflict
sg_sanitize failed: Reservation conflict

Oh that's odd

Maybe the previous system used the SCSI PERSISTENT RESERVATION feature?

Try something like

Code:

sg_persist --clear /dev/sd[x]

You can find a blog post that might help here:

How can I view, create, and remove SCSI persistent reservations and keys. from redhat

solaris/linux sysadmin blog.

dhelios.blogspot.com

(sorry I haven't used this feature myself ever before..)

Whaaat · May 14, 2024

output of "sedutil-cli --scan"?
and
SeaChest_Security -d /dev/*** --tcgInfo --showLockedRegions --showEraseSupport --deviceInfo

mrpasc · May 14, 2024

+ this hint from @Whaaat

https://forums.servethehome.com/index.php?threads/hgst-sas3-ssd-encrypted-need-help-erase.38854/post-363768

Koop · May 14, 2024

Whaaat said:
output of "sedutil-cli --scan"?
and
SeaChest_Security -d /dev/*** --tcgInfo --showLockedRegions --showEraseSupport --deviceInfo

root@truenas[/]# sedutil-cli --scan
Scanning for Opal compliant disks
/dev/sdc E SDLL1CLR020TCDA1 X150
/dev/sdd E SDLL1CLR020TCDA1 X150
/dev/sde E SDLL1CLR020TCDA1 X150
/dev/sdf E SDLL1CLR020TCDA1 X150
No more disks present ending scan

I am guessing this means they support encryption? Part of why I am a bit confused is what seems like conflicting info for if it's actively active or not. sg_readcap shows prot_en=0 which I assumed means encryption is disabled but sg_format shows PROTECT=1 which I assume means, it's on? Or perhaps only supported? Or are these different types of encryption?

OpenSeaChest the same different here? I couldn't seem to find many of the flags you mentioned though. SAS vs SATA only options?

root@truenas[/]# openSeaChest_Security -d /dev/sg4 -i
==========================================================================================
openSeaChest_Security - openSeaChest drive utilities - NVMe Enabled
Copyright (c) 2014-2024 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
openSeaChest_Security Version: 3.3.0-6_2_0 X86_64
Build Date: Apr 23 2024
Today: Tue May 14 11:08:05 2024 User: root
==========================================================================================

/dev/sg4 - SDLL1CLR020TCDA1 - serialhere - X150 - SCSI
Vendor ID: HGST
Model Number: SDLL1CLR020TCDA1
Serial Number: blahblahblah
Firmware Revision: X150
World Wide Name: blahblahblah
Date Of Manufacture: Week 9, 2018
Drive Capacity (TB/TiB): 1.92/1.75
Temperature Data:
Current Temperature (C): 45
Highest Temperature (C): Not Reported
Lowest Temperature (C): Not Reported
Power On Time: 3 years 167 days 14 hours 38 minutes
Power On Hours: 30302.63
MaxLBA: 3750748847
Native MaxLBA: Not Reported
Logical Sector Size (B): 512
Physical Sector Size (B): 4096
Sector Alignment: 0
Rotation Rate (RPM): SSD
Form Factor: 2.5"
Last DST information:
DST has never been run
Long Drive Self Test Time: 1 minute
Interface speed:
Port 0
Max Speed (GB/s): 12.0
Negotiated Speed (Gb/s): 6.0
Port 1
Max Speed (GB/s): 12.0
Negotiated Speed (Gb/s): Not Reported
Annualized Workload Rate (TB/yr): 257.22
Total Bytes Read (TB): 807.04
Total Bytes Written (TB): 82.73
Encryption Support: Self Encrypting
Cache Size (MiB): Not Reported
Percentage Used Endurance Indicator (%): 2.00000
Read Look-Ahead: Enabled
Write Cache: Enabled
SMART Status: Good
ATA Security Information: Not Supported
Firmware Download Support: Full, Segmented, Deferred
Number of Logical Units: 1
Specifications Supported:
SPC-4
Features Supported:
Power Consumption
Write Same
UNMAP
Protection Type 2
TCG
Persistent Reservations
Application Client Logging
Self Test
Automatic Write Reassignment [Enabled]
Automatic Read Reassignment [Enabled]
EPC
Informational Exceptions [Mode 4]
Format Unit
Sanitize
Adapter Information:
Adapter Type: PCI
Vendor ID: 1000h
Product ID: 0097h
Revision: 0002h

NablaSquaredG said:
Oh that's odd

Maybe the previous system used the SCSI PERSISTENT RESERVATION feature?

Try something like

Code:

sg_persist --clear /dev/sd[x]

You can find a blog post that might help here:

How can I view, create, and remove SCSI persistent reservations and keys. from redhat

solaris/linux sysadmin blog.

dhelios.blogspot.com

(sorry I haven't used this feature myself ever before..)

Anything is possible I suppose haha.

I see from reading that persistent reservation is for a system with multiple nodes sharing a single disk, okay makes sense, hmm. Maybe either or both of these things then.

root@truenas[/]# sg_persist --clear /dev/sdd
>> When a service action for Persistent Reserve Out is chosen the
>> '--out' option must be given (as a safeguard)
root@truenas[/]# sg_persist --clear /dev/sdd --out
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR out (Clear): Reservation conflict
sg_persist failed: Reservation conflict

Well seems like it's the the case since it says there is a reservation conflict?

NablaSquaredG · May 14, 2024

Koop said:
Well seems like it's the the case since it says there is a reservation conflict?

Have you looked through the blog article I linked? It has more instructions

Koop · May 14, 2024

NablaSquaredG said:
Have you looked through the blog article I linked? It has more instructions

Ah sorry about that.

root@truenas[/]# sg_persist --in -k -d /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR generation=0x62, 4 registered reservation keys follow:
0xfff12100
0xfff12101
0xfff02100
0xfff02101
root@truenas[/]# root@truenas[/]# sg_persist --in -r -d /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR generation=0x62, Reservation follows:
Key=0x0
scope: LU_SCOPE, type: Write Exclusive, all registrants
root@truenas[/]# sg_persist --out --release --param-rk=0xDEADBEEF --prout-type=5 /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR out (Release): Reservation conflict
sg_persist failed: Reservation conflict
root@truenas[/]# sg_persist --clear --out /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR out (Clear): Reservation conflict
sg_persist failed: Reservation conflict
root@truenas[/]# sg_persist --out --register --param-rk=0xfff12100 /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR out (Register): Reservation conflict
sg_persist failed: Reservation conflict

Hmm so I am guessing there is keys on here. I was just messing with the commands in case I was doing the "--param-rk=" part wrong but doesn't seem like I'm changing anything here. Whole lotta reservation conflicts... Hmm seems like this is on the right track though. Am I doing something bonehead wrong in the above?

Whaaat · May 14, 2024

wrong order, where is sg_persist --out --register --param-sark=xxxx string? It has to be on the 'dead beef' place

nexox · May 14, 2024

From these two sections of the output:

Code:

PR generation=0x62, 4 registered reservation keys follow:
0xfff12100
0xfff12101
0xfff02100
0xfff02101

and

Code:

PR generation=0x62, Reservation follows:
Key=0x0

I think that rather than 0xDEADBEEF you probably want to use 0xfff12100. It could be one of those other three keys I suppose.

Koop · May 14, 2024

Whaaat said:
wrong order, where is sg_persist --out --register --param-sark=xxxx string? It has to be on the 'dead beef' place

Ah I see okay.

root@truenas[/]# sg_persist --out --register --param-sark=0xDEADBEEF /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
root@truenas[/]# sg_persist --in -k -d /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR generation=0x67, 5 registered reservation keys follow:
0xfff12100
0xfff12101
0xfff02100
0xfff02101
0xdeadbeef
root@truenas[/]# sg_persist --out --register --param-rk=0xDEADBEEF /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
root@truenas[/]# sg_persist --in -k -d /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR generation=0x68, 4 registered reservation keys follow:
0xfff12100
0xfff12101
0xfff02100
0xfff02101

root@truenas[/]# sg_persist --out --register --param-sark=0xDEADBEEF /dev/sdd
root@truenas[/]# sg_persist --out --register --param-sark=0xfff12100 /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR out (Register): Reservation conflict
sg_persist failed: Reservation conflict
root@truenas[/]# sg_persist --out --release --param-rk=0xDEADBEEF --prout-type=5 /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR out (Release): bad field in cdb or parameter list (perhaps unsupported service action)
sg_persist failed: Illegal request
root@truenas[/]# sg_persist --out --register --param-rk=0xfff12100 /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR out (Register): Reservation conflict
sg_persist failed: Reservation conflict

Hope you don't need to be on the original system to be able to remove the associated key. that would suck. Doesn't look like I can use any commands to affect the four keys that are already on there? Any idea what to try next? I shall keep reading on sp_persist

nexox · May 14, 2024

I'm just guessing here but I think you need to run --release --param-rk=0xfff12100.

Koop · May 14, 2024

nexox said:
I'm just guessing here but I think you need to run --release --param-rk=0xfff12100.

Oh sorry I did try to do that I must not have put that output in the last post. Without --prout-type it warns you that you need it. So like the blog I set it to 5 but that results in a reservation conflict. Maybe I have to set it to 7 for all registrants- will try that in a sec.

root@truenas[/]# sg_persist --out --release --param-rk=0xfff12100 /dev/sdd
warning>>> --prout-type probably needs to be given
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR out (Release): bad field in cdb or parameter list (perhaps unsupported service action)
sg_persist failed: Illegal request
root@truenas[/]# sg_persist --out --release --param-rk=0xfff12100 --prout-type=5 /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR out (Release): Reservation conflict
sg_persist failed: Reservation conflict

Whaaat · May 14, 2024

you are making some chaotic actions.
From the output you provided:

Code:

 root@truenas[/]# sg_persist --in -r -d /dev/sdd
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
PR generation=0x62, Reservation follows:
Key=0x0
scope: LU_SCOPE, type: Write Exclusive, all registrants
root@truenas[/]# sg_persist --out --release --param-rk=0xDEADBEEF --prout-type=5 /dev/sdd

I would say that you need --prout-type=7

nexox · May 14, 2024

This page seems to be a little more clear about the procedures and specifically the prout-type options: SCSI SPC-3 persistent reservations and fencing

Koop · May 14, 2024

Whaaat said:
you are making some chaotic actions.
From the output you provided:

Code:

root@truenas[/]# sg_persist --in -r -d /dev/sdd HGST SDLL1CLR020TCDA1 X150 Peripheral device type: disk PR generation=0x62, Reservation follows: Key=0x0 scope: LU_SCOPE, type: Write Exclusive, all registrants root@truenas[/]# sg_persist --out --release --param-rk=0xDEADBEEF --prout-type=5 /dev/sdd

I would say that you need --prout-type=7

I appreciate the use of "chaotic" I would personally say "absolutely braindead". Was pretty distracted today while jumping back and forth in my attempt to make progress. Did not help lol.

nexox said:
This page seems to be a little more clear about the procedures and specifically the prout-type options: SCSI SPC-3 persistent reservations and fencing

Really helpful link. It explained things with a bit more context even though it's really just the same commands.

It looks like I was able to remove everything off /dev/sdd as far as I can tell?

root@truenas[/]# sg_persist --in --report-capabilities -v /dev/sdd
inquiry cdb: [12 00 00 00 24 00]
HGST SDLL1CLR020TCDA1 X150
Peripheral device type: disk
Persistent reservation in cdb: [5e 02 00 00 00 00 00 20 00 00]
Report capabilities response:
Replace Lost Reservation Capable(RLR_C): 0
Compatible Reservation Handling(CRH): 0
Specify Initiator Ports Capable(SIP_C): 0
All Target Ports Capable(ATP_C): 1
Persist Through Power Loss Capable(PTPL_C): 1
Type Mask Valid(TMV): 1
Allow Commands: 3
Persist Through Power Loss Active(PTPL_A): 0
Support indicated in Type mask:
Write Exclusive, all registrants: 1
Exclusive Access, registrants only: 1
Write Exclusive, registrants only: 1
Exclusive Access: 1
Write Exclusive: 1
Exclusive Access, all registrants: 1

root@truenas[/]# sg_persist -n -i -k -d /dev/sdd
PR generation=0x0, there are NO registered reservation keys

root@truenas[/]# sg_persist -n -i -r -d /dev/sdd
PR generation=0x0, there is NO reservation held

Seems like one step in the right direction. However looks like I still can't format/use the drive. Still encrypted on top of this I think.

Now I'm getting "sg_sanitize failed: Data protect"

root@truenas[/]# sg_sanitize --crypto /dev/sdd
HGST SDLL1CLR020TCDA1 X150 peripheral_type: disk [0x0]
<< supports protection information>>
Unit serial number:
LU name: 50011731019bb990

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

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

A SANITIZE will commence in 5 seconds
ALL data on /dev/sdd will be DESTROYED
Press control-C to abort
Sanitize failed: Data protect
sg_sanitize failed: Data protect

I can work to get all my drives to this state at least.

Koop · May 15, 2024

Code:

root@truenas[/]# sedutil-cli --PSIDrevertAdminSP <PSID from drive label> /dev/sdc
revertTper completed successfully

Code:

root@truenas[/]# sedutil-cli --query /dev/sdc


/dev/sdc SAS SDLL1CLR020TCDA1 X150 HGST
TPer function (0x0001)
    ACKNAK = N, ASYNC = N. BufferManagement = N, comIDManagement  = N, Streaming = Y, SYNC = Y
Locking function (0x0002)
    Locked = N, LockingEnabled = Y, LockingSupported = Y, MBRDone = N, MBREnabled = N, MBRAbsent = N, MediaEncrypt = Y
Enterprise function (0x0100)
    Range crossing = Y, Base comID = 0x07fe, comIDs = 2

TPer Properties:
  MaxPacketSize = 4076  MaxComPacketSize = 4096
  MaxResponseComPacketSize = 4096  MaxSessions = 1  MaxIndTokenSize = 1026
  MaxAuthentications = 8  MaxTransactionLimit = 1  MaxSubpackets = 1
  MaxPackets = 1  MaxMethods = 1  DefSessionTimeout = 0
  MaxSessionTimeout = 0  MinSessionTimeout = 0
Host Properties:
  MaxSubpackets = 1  MaxPacketSize = 4076
  MaxPackets = 1  MaxComPacketSize = 4096  MaxIndTokenSize = 1026
root@truenas[/]#

It worked! Disk is able to be used now. Is there any additional steps I can take to like, disable self-encrypt? sg_sanitize? I'd rather not have to ever do this again lol ... Can I disable locking as it shows via query?

Thank you @NablaSquaredG and @Whaaat for the guidance! Had no clue about what or how persistent reservations and fencing worked but I feel like I got a real crash course lesson! Logically it all makes sense now. I guess these drives were pulled from some sort of 4 node HA system? Thanks to everyone else as well. Thanks @nexox for the link to that blog that explained things a little deeper that helped!

learned a ton about disk encryption too from this. The TrueNAS page on Self-Encrypting Drives was very helpful in explaining Opal vs Opal 2 vs TCG Enterprise, etc- so many different standards out there. As I googled away I kept running into people who had success with secure erase, etc which I assume only works on SATA drives? Lot of little caveats depending on the encryption being used and type of drive.

Link to the TrueNAS resource on Self-Encrypting Drives:

Self-Encrypting Drives

Describes Self-Encrypting Drive (SED) support on TrueNAS CORE.

www.truenas.com

When I go through the process with my other drives I will document some steps in case someone runs into this in the future.

nabsltd · May 15, 2024

Koop said:
It worked! Disk is able to be used now. Is there any additional steps I can take to like, disable self-encrypt?

Code:

sedutil-cli --disableLockingRange 0 {password from the label} /dev/sdd

or

Code:

sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID {password from the label} /dev/sdd

Koop · May 15, 2024

nabsltd said:

Code:

sedutil-cli --disableLockingRange 0 {password from the label} /dev/sdd

or

Code:

sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID {password from the label} /dev/sdd

Code:

root@truenas[/]# sedutil-cli --disableLockingRange 0 <PSID was here> /dev/sdc
Session Authenticate failed (response = false)

root@truenas[/]# sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID <PSID was here> /dev/sdc
method status code INVALID_FUNCTION

Seems like the same behavior as always there. Feels like it would be a function of sedutil-cli? Or maybe formatting with sg_format --security or something else? I will keep experimenting.

I assume the goal I am trying to achieve is:
LockingEnabled = N

Ultrastar DC SS200 SAS SSDs encrypted (TCG Enterprise?) with SPC-3 PR

Well-Known Member

Attachments

Bringing 100G switches to homelabs

Well-Known Member

Bringing 100G switches to homelabs

Active Member

Well-Known Member

Well-Known Member

Bringing 100G switches to homelabs

Well-Known Member

Active Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Active Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member