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 😁

  • y0din@lemmy.worldEnglish
    5·
    9 hours ago

    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 1
    • Logical blocks are no longer plain 512/4096 bytes (e.g. 520/528 instead)
    • The HBA + driver must explicitly support T10 PI
    • If the controller does not support DIF, the drive may:
      • Be detected
      • But fail all I/O
      • Appear “dead” even though it is healthy

    This 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)
    • Use the correct /dev/sdX

    After this completes and the system is power-cycled, the drive should behave like a normal disk again on non-DIF controllers.

    Important notes

    • sg_format alone almost never permanently damages SAS drives
    • This exact scenario happens frequently when drives are moved between controllers
    • Until tested on a DIF-capable HBA, there is no evidence of permanent failure

    If 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/