How to reformat HDD & SSD to 512B Sector Size

Daylight2751 · Feb 21, 2025

bandit8623 said:
psid [--skip-status] -s <serial number> -p <> [-h]

any luck with hugo?

result:
The current state of the target doesn't require this operation to be performed.

and with the --skip-status flag:
Error: The input string was sent but drive status did not change as expected.

Tuxprogrammer · Mar 20, 2025

Daylight2751 said:
Looks like we're in the same boat. in my case the drives are HGST ultrastar dc hc510 huh721010al5205, but declare themselves as netapp X322_HLBRE10TA07 with NA02 firmware. sg_format/wdckit/hugo fail to format or sanitize, sedutil-cli says the disks are unsupported. The only thing of note would be that running wdckit security --serial JEH6EBTN -p <PSID_HERE> returned "PSID is not activated, PSID revert is not required. Use --skip-status to revert TCG ownership." Running that command again with the given flag returned "Security PSID Revert successfully completed for disk3 User data has not been erased because the drive was not activated", however nothing has changed and i still cant reformat the drives.

I'm having the same issues, I just got in a bunch of Netapp X378 drives (exact same drive, WUS721010AL5205 SED-FIPS except firmware is NA01). I thought I had scored a great deal since they're still in warranty and very low usage. Then trying to use them, I started encountering the dreaded 520 sectors. For me, wdckit fails to format but reports back success. Resetting security with PSID works just fine on my drives. sg_format doesn't work with any combination of flags to disable protect. The only flag that works is setting count=-1 but that doesn't do anything. Drive is connected to a SAS3008 HBA in IT mode and I'm making no progress with sg_format, wdckit, hugo, setblocksize tools. Anyone with advice on disabling NETAPP read/write protect would be welcome.

At this point I might have to return these drives back to the seller because they're write-locked and nothing I do is unlocking them, even resetting the TCG with PSID.

Code:

root@node14:~/setblocksize# sg_format -v --format --size=4096 /dev/sdd --quick
    NETAPP    X378_WVAXE10TA07  NA01   peripheral_type: disk [0x0]
      PROTECT=1
      << supports protection information>>
      Unit serial number: VHGMTR3M     
      LU name: 5000cca0c823ff48
    mode sense(10) cdb: [5a 00 01 00 00 00 00 00 fc 00]
Mode Sense (block descriptor) data, prior to changes:
block count maxed out, set <<longlba>>
    mode sense(10) cdb: [5a 10 01 00 00 00 00 00 fc 00]
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=19532873728 [0x48c400000]
  Block size=512 [0x200]
    mode select(10) cdb: [55 11 00 00 00 00 00 00 24 00]
    Format unit cdb: [04 18 00 00 00 00]
Format unit:
Descriptor format, current; Sense key: Data Protect
Additional sense: Access denied - no access rights
  Descriptor type: Field replaceable unit code: 0x27
  Descriptor type: Vendor specific [0x80]
    f8 27
Format unit command: Data protect, type: sense key; write protected media?
FORMAT UNIT failed

Code:

root@node14:~# smartctl -a /dev/sdd
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-8-pve] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               NETAPP
Product:              X378_WVAXE10TA07
Revision:             NA01
Compliance:           SPC-4
User Capacity:        9,949,895,720,960 bytes [9.94 TB]
Logical block size:   520 bytes
Physical block size:  4160 bytes
LU is fully provisioned
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      0x5000cca0c823ff48
Serial number:        VHGMTR3M
Device type:          disk
Transport protocol:   SAS (SPL-4)
Local Time is:        Thu Mar 20 19:16:41 2025 CDT
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Grown defects during certification <not available>
Total blocks reassigned during format <not available>
Total new blocks reassigned <not available>
Power on minutes since format <not available>
Current Drive Temperature:     32 C
Drive Trip Temperature:        65 C

Accumulated power on time, hours:minutes 49:54
Manufactured in week 47 of year 2022
Specified cycle count over device lifetime:  50000
Accumulated start-stop cycles:  37
Specified load-unload count over device lifetime:  600000
Accumulated load-unload cycles:  39
Elements in grown defect list: 0

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0        0        25         0        612         15.748           0
write:         0        0         0         0        725      19901.898           0
verify:        0        0         0         0        250          3.704           0

Non-medium error count:      329

No Self-tests have been logged

Code:

Avago Technologies SAS3 Flash Utility
Version 15.00.00.00 (2016.11.17)
Copyright 2008-2016 Avago Technologies. All rights reserved.

        Adapter Selected is a Avago SAS: SAS3008(C0)

        Controller Number              : 0
        Controller                     : SAS3008(C0)
        PCI Address                    : 00:01:00:00
        SAS Address                    : ...
        NVDATA Version (Default)       : 0a.00.30.26
        NVDATA Version (Persistent)    : 0a.00.30.26
        Firmware Product ID            : 0x2221 (IT)
        Firmware Version               : 10.00.03.00
        NVDATA Vendor                  : LSI
        NVDATA Product ID              : LSI3008-IT
        BIOS Version                   : 08.25.00.00
        UEFI BSD Version               : 12.00.00.00
        FCODE Version                  : N/A
        Board Name                     : LSI3008-IT
        Board Assembly                 : N/A
        Board Tracer Number            : N/A

        Finished Processing Commands Successfully.
        Exiting SAS3Flash.

Code:

root@node14:~/sedutil-1.49.8# ./sedutil-cli --query /dev/sdd
/dev/sdd OTHER   X378_WVAXE10TA07  NA01   NETAPP 
TPer function (0x0001)
    ACKNAK = N, ASYNC = N. BufferManagement = N, comIDManagement  = N, Streaming = Y, SYNC = Y
Locking function (0x0002)
    Locked = N, LockingEnabled = Y, MBR shadowing Not Supported = N, MBRDone = N, MBREnabled = N, MediaEncrypt = Y
Geometry function (0x0003)
    Align = Y, Alignment Granularity = 8 (4160), Logical Block size = 520, Lowest Aligned LBA = 0
Enterprise function (0x0100)
    Range crossing = N, Base comID = 0x07fe, comIDs = 2
BlockSID function (0x0402)
    BlockSIDState = N, SIDvalueState = 1, HardReset  = 0

mrpasc · Mar 21, 2025

Try to remove the write protection this way:

https://www.reddit.com/r/homelab/s/jAUmwUV5vk

Tuxprogrammer · Mar 21, 2025

Daylight2751 said:
result:
The current state of the target doesn't require this operation to be performed.

and with the --skip-status flag:
Error: The input string was sent but drive status did not change as expected.

I found a solution!!!!

use this fork: GitHub - Mattiwatti/sedutil: DTA sedutil Self encrypting drive software of sedutil-cli
I built from source on a debian proxmox 8.3.5 host.
perform a psid reset like:
./sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID my20characterPSIDfromWDLabelortheQRcodeHERE /dev/sdd

then you can perform a format like:
sg_format -v --format --size=4096 /dev/sdd --quick

Code:

root@node14:~/sedutil# ./sedutil-cli --yesIreallywanttoERASEALLmydatausingthePSID redacted /dev/sdd
revertTper completed successfully

Code:

root@node14:~/sedutil# sg_format -v --format --size=4096 /dev/sdd --quick
    NETAPP    X378_WVAXE10TA07  NA01   peripheral_type: disk [0x0]
      PROTECT=1
      << supports protection information>>
      Unit serial number: VHGMTR3M       
      LU name: 5000cca0c823ff48
    mode sense(10) cdb: [5a 00 01 00 00 00 00 00 fc 00]
Mode Sense (block descriptor) data, prior to changes:
  Number of blocks=2441609216 [0x91880000]
  Block size=4096 [0x1000]
    Format unit cdb: [04 18 00 00 00 00]
Format unit command launched without error

Format unit has started
Format unit in progress, 0.05% done
Format unit in progress, 0.22% done
Format unit in progress, 0.38% done
Format unit in progress, 0.55% done

ojhavary · Apr 16, 2025

I'm having a difficult time trying to format a 7.8TB Huawei drive to 512 format. This is the drive info:

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-5.4.0-150-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor: HUAWEI
Product: HSSD-D7G23AN7T6N
Revision: 8308
Compliance: SPC-4
User Capacity: 7,801,524,581,760 bytes [7.80 TB]
Logical block size: 520 bytes
Physical block size: 8320 bytes
LU is resource provisioned, LBPRZ=1
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Logical Unit id: 0x500188200177e4e2
Serial number: 2102314LLJFSQ1004781
Device type: disk
Transport protocol: SAS (SPL-3)
Local Time is: Wed Apr 16 11:27:27 2025 SAST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Temperature Warning: Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Percentage used endurance indicator: 0%
Current Drive Temperature: 35 C
Drive Trip Temperature: 78 C

Manufactured in week 12 of year 2023
Specified cycle count over device lifetime: 0
Accumulated start-stop cycles: 27
Specified load-unload count over device lifetime: 0
Accumulated load-unload cycles: 0
Elements in grown defect list: 0

ojhavary · Apr 16, 2025

This is the result of the sg_format. What am I missing?

sg_format --format --size=512 --six /dev/sg1 -v
HUAWEI HSSD-D7G23AN7T6N 8308 peripheral_type: disk [0x0]
PROTECT=1
<< supports protection information>>
Unit serial number: 2102314LLJFSQ1004781
LU name: 500188200177e4e2
mode sense (6) cdb: 1a 00 01 00 fc 00
Mode Sense (block descriptor) data, prior to changes:
Mode sense number of blocks maxed out, set longlba
mode sense (10) cdb: 5a 10 01 00 00 00 00 00 fc 00
Mode Sense (block descriptor) data, prior to changes:
<<< longlba flag set (64 bit lba) >>>
Number of blocks=15002931888 [0x37e3e92b0]
Block size=520 [0x208]
mode select (10) cdb: 55 11 00 00 00 00 00 00 22 00
mode select (10):
Descriptor format, current; Sense key: Illegal Request
Additional sense: Parameter list length error
Descriptor type: Information: 0x0000000000000000
MODE SELECT command: Illegal request sense key, apart from Invalid opcode

Arslan109 · May 29, 2025

I too have a IBM Branded seagate ST1600FM0013. After trying everything, nothing worked.
so i took the ssd to my laptop repairing friend andasked him to read be the contents of the firmware file.

so if anyone has any knowledge of editing bin files, can someone edit it and maybe the r

ST1600FM0013.BIN

drive.google.com

leromarinvit · Sep 25, 2025

Do you know how he dumped the firmware? Reverse engineering it is one possibility, but writing Seagate firmware to the drive instead might be even easier. If he was able to find JTAG pins on the PCB or on that 20 pin connector to read it, writing should also be possible.

This should be the right firmware for your drive: https://apps1.seagate.com/downloads/certificate.html?action=performDownload&key=1540915305777

jabuzzard · Sep 25, 2025

leromarinvit said:
Do you know how he dumped the firmware? Reverse engineering it is one possibility, but writing Seagate firmware to the drive instead might be even easier. If he was able to find JTAG pins on the PCB or on that 20 pin connector to read it, writing should also be possible.

This should be the right firmware for your drive: https://apps1.seagate.com/downloads/certificate.html?action=performDownload&key=1540915305777

Most of the firmware for a hard drive is stored on the spinning platters. It harks back to a time when flash memory was significantly more expensive than it is today. Basically, the flash holds just enough to spin the drive up and load the rest from the platters. You can see this sometimes when the bit holding the firmware on the platters goes bad, and the drive will start reporting incorrectly (with the wrong name and capacity, generally) as it has been unable to download the rest of the firmware from the drive.

In 2025, it's frankly nuts to still do this, as the smallest flash chip you can buy will comfortably hold all the firmware, but that's just the way it is.

leromarinvit · Sep 25, 2025

jabuzzard said:
Most of the firmware for a hard drive is stored on the spinning platters.

I knew this was the case for HDDs, but does that still hold for SSDs? I don't know what SoCs they're using (at least for my ST3200FM0033 it seems to be some Broadcom/Avago chip I wasn't able to find any info on), but the ones I know can boot from SPI flash chips, but not from the oodles of NAND flash that make up the main storage. Splitting it up into a bootloader stored somewhere else and a main firmware image on the main flash seems way more trouble than it's worth...

Anyway, this still leaves the question of how to access the firmware out of band. AFAIK there are standard SCSI commands for writing new firmware (helpfully locked by IBM in this particular case), but not for reading it. Yet, clearly someone was able to dump the IBM firmware, so it must be possible somehow. And whatever was done to read it could likely also be used for writing, to get rid of the IBM stuff.

Arslan109 · Sep 25, 2025

leromarinvit said:
Do you know how he dumped the firmware? Reverse engineering it is one possibility, but writing Seagate firmware to the drive instead might be even easier. If he was able to find JTAG pins on the PCB or on that 20 pin connector to read it, writing should also be possible.

This should be the right firmware for your drive: https://apps1.seagate.com/downloads/certificate.html?action=performDownload&key=1540915305777

So, what we did is we opened the ssd, then on the board there was a laptop like bios chip. So i took that to him, he removed it with a heat gun and then used his programmer to read the contents of the file.

The link you have sent, i have also downloaded it. But the issue is that, the ssd’s firmware is stored as .bin but the one Seagate provides in this link is LOD.
If there is any way to get the .bin just upload that i can test it as i still have the opened ssd with me

Arslan109 · Sep 25, 2025

jabuzzard said:
Most of the firmware for a hard drive is stored on the spinning platters. It harks back to a time when flash memory was significantly more expensive than it is today. Basically, the flash holds just enough to spin the drive up and load the rest from the platters. You can see this sometimes when the bit holding the firmware on the platters goes bad, and the drive will start reporting incorrectly (with the wrong name and capacity, generally) as it has been unable to download the rest of the firmware from the drive.

In 2025, it's frankly nuts to still do this, as the smallest flash chip you can buy will comfortably hold all the firmware, but that's just the way it is.

This is an ssd, we just opened it by unscrewing the screws. And on the pcb it contained the Nand chips ( i think thats what its called) and near the top toward the sas connector there was a chip that stored the .bin file. Didnt see the exact model of the chip. But we read that to get the bin file

Arslan109 · Sep 25, 2025

leromarinvit said:
I knew this was the case for HDDs, but does that still hold for SSDs? I don't know what SoCs they're using (at least for my ST3200FM0033 it seems to be some Broadcom/Avago chip I wasn't able to find any info on), but the ones I know can boot from SPI flash chips, but not from the oodles of NAND flash that make up the main storage. Splitting it up into a bootloader stored somewhere else and a main firmware image on the main flash seems way more trouble than it's worth...

Anyway, this still leaves the question of how to access the firmware out of band. AFAIK there are standard SCSI commands for writing new firmware (helpfully locked by IBM in this particular case), but not for reading it. Yet, clearly someone was able to dump the IBM firmware, so it must be possible somehow. And whatever was done to read it could likely also be used for writing, to get rid of the IBM stuff.

As i mentioned in my above replys, we just brute forced it like. Using the heatgun to remove the chip and putting it in a bios programmer to read the contents. Was a simple process in my opinion u just need a heatgun and it comes out in like 30 seconds

leromarinvit · Sep 26, 2025

Someone has analyzed the LOD file format here: https://forum.hddguru.com/viewtopic.php?f=13&t=28252

I tried the script, but it only extracted the headers from the Koho firmware. I haven't looked into the actual description of the file format or the script yet to see if it just needs to be adapted a little.

Best would be if someone with a Koho SSD with Seagate firmware could dump it. Mine also have IBM firmware (else I wouldn't be here...) - I need to take one apart a little further some time. I saw what looks like a Winbond labeled chip on a photo of the underside of the PCB (not the usual SOIC package though - looked like QFN/DFN or BGA) - that could be it.

Photos: https://forums.servethehome.com/ind...anded-micron-s650dc-800-ssd.26945/post-423485

Edit: Alright, took it apart and found the chip. It's a W25Q32FWZEIG in WSON-8 8x6mm package. Easy to desolder, maybe possible to solder thin wires directly or clamp it with something like this. But also not much use without having a flash dump of a good drive or understanding the LOD format first.

Arslan109 · Sep 26, 2025

leromarinvit said:
Someone has analyzed the LOD file format here: https://forum.hddguru.com/viewtopic.php?f=13&t=28252

I tried the script, but it only extracted the headers from the Koho firmware. I haven't looked into the actual description of the file format or the script yet to see if it just needs to be adapted a little.

Best would be if someone with a Koho SSD with Seagate firmware could dump it. Mine also have IBM firmware (else I wouldn't be here...) - I need to take one apart a little further some time. I saw what looks like a Winbond labeled chip on a photo of the underside of the PCB (not the usual SOIC package though - looked like QFN/DFN or BGA) - that could be it.

Photos: https://forums.servethehome.com/ind...anded-micron-s650dc-800-ssd.26945/post-423485

Edit: Alright, took it apart and found the chip. It's a W25Q32FWZEIG in WSON-8 8x6mm package. Easy to desolder, maybe possible to solder thin wires directly or clamp it with something like this. But also not much use without having a flash dump of a good drive or understanding the LOD format first.

I

If you figure out how to modify the bin file. Try to reconfigure my file so i can try it as i have already taken it apart and changing the firmware isn’t difficult for me.

the clamp you have sent, i wouldn’t recommend it. Best is to remove the physical chip as those clamps are a pain in the …

therem · Nov 2, 2025

azev said:
For those of you who have purchased OEM rebranded HDD or SSD from major storage vendor such as NetApp, EMC, or even HP, you might find out that the drive that you've purchased will not initialized in windows. The main reason is that the drive come formatted from the factory with a non standard sector size of 520B or 528B, and windows refused to initialized drive other than the normal 512B or 4Kb. I read online the reason that these drive are formatted that way is due to some proprietary software that these vendor uses needs the additional sector size for some fancy parity stuff.

Anyway, you probably think that you are SOL after trying every possible means to use the drive.
Luckily there is a way to change the drive sector back to 512B. It require that you install centOS linux and follow the instruction below

Look in /var/log/messages after reboot, and you will see useful information:

Mar 9 08:08:54 vhc-carthage kernel: sd 6:0:7:0: [sdh] Attached SCSI disk
Mar 9 08:08:57 vhc-carthage kernel: ...ready
Mar 9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] Unsupported sector size 520.
Mar 9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] 0 512-byte logical blocks: (0 B/0 B)
Mar 9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] 520-byte physical blocks
Mar 9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] Write Protect is off
Mar 9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] Write cache: disabled, read cache: enabled, supports DPO and FUA
Mar 9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] Unsupported sector size 520.
Mar 9 08:08:57 vhc-carthage kernel: sd 6:0:8:0: [sdi] Attached SCSI disk

# yum install sg3_utils

# sg_scan -i
/dev/sg8: scsi6 channel=0 id=7 lun=0
NETAPP X287_S15K5288A15 NA00 [rmb=0 cmdq=1 pqual=0 pdev=0x0]
/dev/sg9: scsi6 channel=0 id=8 lun=0
NETAPP X287_S15K5288A15 NA00 [rmb=0 cmdq=1 pqual=0 pdev=0x0]

Now you should format the offending drive using the "sg_format" command.
[root@azev /]# sg_format --format --size=512 /dev/sg8

NETAPP X287_S15K5288A15 NA00 peripheral_type: disk [0x0]
Mode Sense (block descriptor) data, prior to changes:
Number of blocks=573653847 [0x22314357]
Block size=520 [0x208]

A FORMAT will commence in 10 seconds
ALL data on /dev/sg8 will be DESTROYED
Press control-C to abort

It is pretty simple, and after the format is completed, you should have no problem initializing the drive in Windows. However, per Patrick, some drive might require that you've bring the drive offline and then online before it would allow you to format it.

Some people argue that the custom firmware on the drive is set to work with sector size 520B or 528B, but during my benchmark, the drive performance was pretty much on par with the normal retail channel.

Hopefully you find this information useful next time you come across a drive with other than 512B sector size.

I would really like to thank you. I successfully managed to esay re-format EMC3200 3.2TB 520B sectors size SSDs (Toshiba PX05SRB384) to 512B/4KB standard sectors size. They are now usable like standard SAS 512e SSD drive in any server, any controller and any OS

leromarinvit · Nov 15, 2025

Arslan109 said:
If you figure out how to modify the bin file. Try to reconfigure my file so i can try it as i have already taken it apart and changing the firmware isn’t difficult for me.

I haven't yet figured out how to map the LOD file to the physical flash layout - but I've bought a Seagate-branded ST200FM0133 (200GB, cheapest Koho drive I could find) and dumped its firmware. It came with 0007 - I dumped that, upgraded to 000A, and dumped that as well. So now we have both the LOD and a flash dump for version 000A - hopefully that's enough to understand the file format. Or, with some luck, blindly flashing the Seagate dump to the IBM-branded drive might just work...

I found a Python script that parses LOD files here: GitHub - eurecom-s3/hdd_firmware_tools: Tools for viewing and extracting HDD firmware files. I've forked it and started adapting it to make sense of the Koho LODs, but with just the IBM dump and the Seagate LOD, I didn't get very far. I haven't yet looked at it again since getting the Seagate dumps, but I will when I can find some time.

I've uploaded the dumps here in case anyone wants to play around with them:

seagate_ST200FM0133_0007.bin

drive.google.com

seagate_ST200FM0133_000A.bin

drive.google.com

Arslan109 said:
the clamp you have sent, i wouldn’t recommend it. Best is to remove the physical chip as those clamps are a pain in the …

You're absolutely right, that thing is a PITA to use. I did manage to get two good dumps (verified by dumping twice and comparing), but only after desoldering - at which point a socket adapter would likely have been much easier to use. But that's still in transit and I was impatient, so...

Dave Corder · Nov 16, 2025

leromarinvit said:
I haven't yet figured out how to map the LOD file to the physical flash layout - but I've bought a Seagate-branded ST200FM0133 (200GB, cheapest Koho drive I could find) and dumped its firmware. It came with 0007 - I dumped that, upgraded to 000A, and dumped that as well. So now we have both the LOD and a flash dump for version 000A - hopefully that's enough to understand the file format. Or, with some luck, blindly flashing the Seagate dump to the IBM-branded drive might just work...

I found a Python script that parses LOD files here: GitHub - eurecom-s3/hdd_firmware_tools: Tools for viewing and extracting HDD firmware files. I've forked it and started adapting it to make sense of the Koho LODs, but with just the IBM dump and the Seagate LOD, I didn't get very far. I haven't yet looked at it again since getting the Seagate dumps, but I will when I can find some time.

I've uploaded the dumps here in case anyone wants to play around with them:

seagate_ST200FM0133_0007.bin

drive.google.com

seagate_ST200FM0133_000A.bin

drive.google.com

You're absolutely right, that thing is a PITA to use. I did manage to get two good dumps (verified by dumping twice and comparing), but only after desoldering - at which point a socket adapter would likely have been much easier to use. But that's still in transit and I was impatient, so...

I'm watching this with great interest, wondering if there's anything that will come out of this that might help flash IBM-branded Seagate HDDs to Seagate firmware...

8BitZach · Dec 15, 2025

Hello all, I am working with some Netapp 4TB SAS HDDs - Toshiba, WD, Seagate. Reblocking them to 512 is no problem, but the X375_SMBPE04TA07 ST4000NM0125 will not show any SMART data, and the WD drives show it without issue. (The Toshiba drives may be the same way, but I have not dug into those yet)

Does anyone know of a way to expose this data or cross-flash the drive with generic Seagate firmware?

mythic · Dec 25, 2025

Ran into the DIF error on every drive in my R740XD - spent $40 and solved the problem instead of spending hours hacking away at firmware to disable Enterprise security and then even more hours performing a low-level format on every single drive.

Swapped the HBA330 for the H740P from my other R740 and the error went away. Tested on my other hardware and the problem seems isolated to the HBA330.

Is there a remotely compelling reason to risk bricking my drives or spending hours on the reformat when the hardware swap works?

Specs:
Dell PowerEdge R740xd
HBA330 (0P2RXR)
12x 0GW8T1 DELL PM1645a 800GB MZ-ILT800C MZILT800HBHQAD3 118000842 12G SAS SSD
12x 0XY986 DELL ST2000NX0273 2TB 2.5" 7.2K RPM 12Gb/s SAS 512e

R240/R440/R740 in the same rack have never had this problem using the exact same drives:
R240 - PERC H740p (DPHNJ) in a PCI slot in Enhanced HBA mode
R440 - PERC H330 (75D1H) in PCI slot in Pass-through mode
R740 - PERC H740 Mini mono (05FMY4) in Enhanced HBA mode

How to reformat HDD & SSD to 512B Sector Size

New Member

New Member

Well-Known Member

New Member

New Member

New Member

New Member

New Member

Member

New Member

New Member

New Member

New Member

New Member

New Member

New Member

New Member

Well-Known Member

New Member

New Member