this post was submitted on 26 Dec 2025
-33 points (34.9% liked)

Selfhosted

53914 readers
504 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:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

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

Questions? DM the mods!

founded 2 years ago
MODERATORS
-33
submitted 12 hours ago* (last edited 12 hours ago) by rook@lemmy.zip to c/selfhosted@lemmy.world
 

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...

Edit: 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 😞

you are viewing a single comment's thread
view the rest of the comments
[–] y0din@lemmy.world 20 points 6 hours ago* (last edited 5 hours ago)

Right now there isn’t enough information to conclude that the drive is “bricked”.

sg_format on a SAS drive with DIF enabled can absolutely make the disk temporarily unusable to the OS if the format parameters no longer match what the HBA/driver expects, but that is very different from a dead drive.

To make any determination, more data is required. At minimum (boot with a live Linux USB drive if you are unable to get to this information):

Please provide verbatim output from:

  • dmesg -T (from boot and when the drive is detected)
  • sblk -o NAME,MODEL,SIZE,PHY-SeC,LOG-SeC
  • fdisk -l /dev/sdX
  • sg_inq /dev/sdX
  • sg_readcap -l /dev/sdX
  • sg_modes -a /dev/sdX

Also specify:

  • Exact drive model
  • HBA model and firmware
  • Kernel version / distro
  • Whether the controller supports DIF/DIX (T10 PI)
  • Whether other identical drives still work in the same slot/cable

Common possibilities (none can be confirmed without logs):

  • Drive formatted with DIF enabled but HBA/OS not configured for it
  • Logical/physical block size mismatch (e.g. 520/528 vs 512/4096)
  • Format still in progress or left the drive in a non-ready state
  • Mode pages changed that Linux does not like by default

Things that are usually recoverable on SAS drives:

  • Re-formatting with correct sector size and DIF disabled
  • Clearing protection information
  • Power-cycling the drive after format completion
  • Formatting from a controller that fully supports the drive’s feature set

Actual permanent bricking from sg_format alone is rare unless firmware flashing or vendor-specific commands were involved.

Until logs are posted, all anyone can honestly say is:

The drive is not currently usable, but there is no evidence yet that it is permanently damaged.

If you can share this information it might be possible to get the drive back online, though I make no promises.

(edit typos)