Did I just brick my SAS drive?
I was trying to make a pool with the other 5 drives and this one kept giving errors. As a completer beginner I turned to gpt.....
What can I do? Is that drive bricked for good?
Don't clown on me, I understand my mistake in running shell scripts from Ai...
EMPTY DRIVES NO DATA
The initial error was:
Edit: sde and SDA are the same drive, name just changed for some reason And also I know it was 100% my fault and preventable 😞
**Edit: ** from LM22, output of sudo sg_format -vv /dev/sda
BIG EDIT:
For people that can help (btw, thx a lot), some more relevant info:
Exact drive model: SEAGATE ST4000NM0023 XMGG
HBA model and firmware: lspci | grep -i raid 00:17.0 RAID bus controller: Intel Corporation SATA Controller [RAID mode] Its an LSI card Bought it here
Kernel version / distro: I was using Truenas when I formatted it. Now trouble shooting on other PC got (6.8.0-38-generic), Linux Mint 22
Whether the controller supports DIF/DIX (T10 PI): output of lspci -vv
Whether other identical drives still work in the same slot/cable: yes all the other 5 drives worked when i set up a RAIDZ2 and a couple of them are exact same model of HDD
COMMANDS This is what I got for each command: verbatim output from
Thanks for all the help 😁
One more hopefully happy update:
Based on everything you’ve shown so far in the information you have given, the most probable cause is that the drive was formatted with T10 DIF / Protection Information enabled (
PROTECT=1), and you are now accessing it through a controller path that does not support DIF.This is a very common failure mode with enterprise SAS drives and
sg_format.(edit: oh, how I am in a love/hate relationship with my brain on delayed thoughts...)
In your paste from sg_format you can see this flag:
sudo sg_format -vv /dev/sda open /dev/sda with flags=0x802 inquiry cdb: [12 00 00 00 24 00] SEAGATE ST4000NM0023 XMGG peripheral_type: disk [0x0] PROTECT=1(end of edit)
What this means in practice:
PROTECT=1= the drive was formatted with DIF Type 1This is not bricking. It is a configuration mismatch.
How to fix it (most reliable path)
You need to connect the drive to a DIF-capable SAS HBA (LSI/Broadcom, same type as originally used if possible).
Best option is to do this on the original hardware, even via a USB live Linux environment.
Once the drive is on a T10-capable controller, reformat it with protection disabled.
Example (this will ERASE the drive and might take a LONG time to complete):
sudo sg_format --format --size=512 --fmtpinfo=0 --pfu=0 /dev/sdX
Key flags:
--fmtpinfo=0→ disables DIF / PROTECT--size=512(or 4096 if you prefer standard 4K)--pfu=0(disables PROTECTION flag, your GPT forgot to include this which actually disables the protection)/dev/sdXAfter this completes and the system is power-cycled, the drive should behave like a normal disk again on non-DIF controllers.
Important notes
sg_formatalone almost never permanently damages SAS drivesIf you cannot access a T10-capable controller, the drive may remain unusable on that system, but still be perfectly recoverable elsewhere.
A case of a user with another problem but where he needed to disable DIF, got it fixed after a new format with these parameters (from Google):
https://www.truenas.com/community/threads/drives-formatted-with-type-1-protection-eventually-lead-to-data-loss.86007/