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
    1·
    11 hours ago

    Thanks for the update, that’s helpful.

    Confirming that the controller is a Broadcom / LSI SAS2308 and that it’s the same HBA that was used in the original TrueNAS system removes one major variable. It means the drive is now being tested under the same controller path it was previously attached to.

    The device mapping you described is clear:

    sda = known-good identical drive

    sdb = the problematic drive

    Running:

    sudo sg_format --format --size=512 --fmtpinfo=0 --pfu=0 /dev/sdb

    as you did is the correct next step to normalize the drive’s format and protection settings.

    A few general notes while this is in progress:

    • Some drives report completion before all internal states are fully settled, which will cause reduced performance as the operation continues until finished in the background
    • A power cycle after completion is recommended before testing the drive again

    At this point it makes sense to pause any further investigation until the current sg_format has fully completed and the system has been power-cycled.

    Once that’s done, the next step will be a direct comparison between sdb and the known-good sda using:

    sudo sg_readcap -lla

    • Reported logical and physical sector sizes

    • Protection / PI status

    As a general note going forward: on Linux / FreeBSD it’s safer to reference disks by persistent identifiers (e.g. /dev/disk/by-id/ or UUID (this is safer but not so direct human readable) on Linux or glabel on FreeBSD) rather than /dev/sdX, as device names can change across boots or hardware reordering as you have had some experience with now.

    Post the results when you’re ready and the sg_format complete and we can continue from there.