this post was submitted on 26 Dec 2025
-45 points (36.5% liked)

Selfhosted

60723 readers
138 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.

  8. AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

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 (broken link)

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 (broken link)

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: (broken link)


Solved by y0din! Thank you soo much!


Thanks for all the help ๐Ÿ˜

you are viewing a single comment's thread
view the rest of the comments
[โ€“] y0din@lemmy.world 7 points 6 months ago* (last edited 6 months 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/