"HPA/DCO data unavailable, cannot determine hidden sector status" and DIF/DIX (aka PI) protection Information field or type 2 formatting.

[thebearnecessities]

Hi there, Is there anyway of getting nwipe to not give this error, because its not a security/data risk I care about, but it might freak out the person who gets the report lol.

[thebearnecessities]

perhaps there a method or PRNG that doesn't check for HPA/DCO?

[PartialVolume]

A command line option to disable HPA/DCO could be added, this would have to be reflected in the report that HPA/DCO check is disabled, but would give a green tick and no warnings.

How many drives do you see this on and are you using the very latest version of nwipe?

I'd like to hear what others feel about HPA/DCO checks and what the message might be for a drive that won't respond to HPA/DCO commands like some recent enterprise discs and discs attached via some usb adapters.

[DaanSelen]

@thebearnecessities Any donations are always welcome as it does help towards the purchase of some of the hardware. Either via github at https://github.com/sponsors/PartialVolume or via https://www.buymeacoffee.com/Shredos

I'll see if I can improve HPA/DCO status reporting when it comes to ??? Identifying the drive as not supporting HPA/DCO so it responds with a more appropriate HS? N/A and without the exclamation is definitely preferable if nwipe knows the drive doesn't support HPA/DCO. SAS especially could do with some improvement. SATA, I think seems to be generally ok but there maybe some drives to don't support it.

Has there been any progress in this processing of HPA/DCO? I have recently encountered a drive which also seems to be weirded out with this.

[PartialVolume]

Yes, a patch was merged a while back to exclude SAS from HPA/DCO detection as the SAS protocol doesn't support HPA/DCO. I believe the ATA standard may have dropped the HPA/DCO commands with the most recent revision and I believe some more recent Seagate Enterprise no longer support the commands.

I'd need to know the make/model of your drive and a copy of the nwipe l og in verbose or diagnostic mode. sudo nwipe -v --logfile=log.txt. no need to wipe anything, just start nwipe, wait until it gets to the drive selection screen and abort with a control c and then post the file log.txt.

[DaanSelen]

Yes, a patch was merged a while back to exclude SAS from HPA/DCO detection as the SAS protocol doesn't support HPA/DCO. I believe the ATA standard may have dropped the HPA/DCO commands with the most recent revision and I believe some more recent Seagate Enterprise no longer support the commands.

I'd need to know the make/model of your drive and a copy of the nwipe l og in verbose or diagnostic mode. sudo nwipe -v --logfile=log.txt. no need to wipe anything, just start nwipe, wait until it gets to the drive selection screen and abort with a control c and then post the file log.txt.

Can I submit its report with make and model to you somehow? It has some customer data I don't want out there if not necessary.

[PartialVolume]

Yes, email shredos.eraser@gmail.com

[DaanSelen]

I have sent you the report.

[bandit8623]

just ran 80 drives. all of them gave this error. these are 4kn drives with type 2 protection enabled. on a second batch of these many just plain failed to finish wiping alltogether. reran wipe using a different program and wiped fine so drives are not bad.

getting rid of this error/ warning would be ideal

.36 version running on mint

SEAGATE ST8000NM0065

vendor: SEAGATE
product: ST8000NM0065
revision: K004
compliance: SPC-4
user capacity: 8,001,563,222,016 bytes [8.00 TB]
logical block size: 4096 bytes
formatted with type 2 protection
8 bytes of protection information per logical block
lu is fully provisioned
rotation rate: 7200 rpm
form factor: 3.5 inches

[bandit8623]

i/o errors. i even rebuilt a new system and swapped raid card . made no diff.
zeros .no verification. no last pass
yes same zero wipe
killdisk industrial
all non raid using lastest firmware on lsi 2308 it mode hbas.

[PartialVolume]

Interesting, how far into the wipe would you say it got before failing with an I/O errors?

[PartialVolume]

I'm not familiar with killdisk industrial but a quick review of the manual suggests that write error detection can be disabled in the processing attributes, assuming I've understood it correctly. I'm just checking, but I'm assuming you had write error detection enabled?

ShredOS/nwipe always aborts on the first write error it detects by design, however an option to override this maybe be in the pipeline. That's why I'm interested in how far it got in percentage before generating an I/O error.

[bandit8623]

10% then i/o errors on 3 to 4 drives . left run over night and all but 3 had failed to i/o errors by morning. i/o error code -1.

tried 3 diff times diff system and cards, all errors seemed to happen around the same time each run.

[PartialVolume]

10% is a long way into the drive and if three drives wiped ok it would suggest that nwipes ability to write and sync the drive is working ok. When the drive syncs the os is told to flush the disc cache to the disc. The return status is then detected as provided by fdatasync to determine whether the data was written to the disc without any write error. Nwipe would then terminate that particular wipe as the disc would then be destined for physical destruction.

So, how to prove where the problem is?

• Confirm killdisc industrial processing attributes are set to detect write errors.
• use the verify zeros method in nwipe to check if the disc is zero wiped by kill disc.
• what's the reallocated sector count like on the drives that fail? Have a lot of sectors been reallocated or is it in good shape, i.e zero reallocated sectors.

[bandit8623]

by default we have ignore read and write, because we need the wipe to finish no matter what. actually that would be a good option to add to nwipe.
actualy default for killdisk is to ignore read and write errors.. we leave default there

all the drives are 100% health. no realocated sectors. no read or write errors.

wondering if its more to do with the type 2 protection. example - i know trunas core has issues with it but trunas scale can handle. just throwing out ideas

health.txt

[PartialVolume]

all the drives are 100% health. no realocated sectors. no read or write errors.

Not all are at 100% health, there's 3 drives amongst those 84 that are reporting 0% health, imminent failure.

wondering if its more to do with the type 2 protection. example - i know trunas core has issues with it but trunas scale can handle. just throwing out ideas

That's a possibility, personally I've not tested with drives that are type 2 protection formatted. As I've read, the controller formats them as a slightly larger size than 512 or 4096 and uses that as some error correction? But presents the correct block size back to the OS. Apparently they can be reformatted as standard blocks but I guess it depends on the controller.

Anybody that has a better knowledge of these drives please feel free to jump in.

[bandit8623]

yep. using .36.

and thanks!

[fthobe]

Hey @PartialVolume @bandit8623 I know I am late to the party.

https://github.com/gms-electronics/formatingguide

Instructions to reformat disks with protection.

[PartialVolume]

@fthobe useful guide, maybe worth putting a mention in ShredOS's readme specially about 512k reformatting.

[fthobe]

@PartialVolume the reason why I asked for parallel was to execute multiple sg_format commands at once as it seems to be the only way to execute a reformat on Linux on 520 or other special sector drives.
@doug-gilbert what's the default modus operandi with sg_format, all 0?

[fthobe]

@fthobe useful guide, maybe worth putting a mention in ShredOS's readme specially about 512k reformatting.

Done, PR raised.

[bandit8623]

killdisk at about 50% done no stops yet. ill run them again using nwipe after. may be a few days before i get info for you.
edit-
ill just stop the killdisk as i know it will go through and rerun the nwipe to get logs faster.

[kevin-bbinc]

Similar to u/thebearnecessities, I'm also clearing drives for donations.

Forgive my ignorance, but is it possible that this affects SAS drives specifically? I recently cleared 8 drives, 1 SATA and 7 SAS, and the SATA drive cleared as expected without any warnings in the report. I googled if HPA/DCO is an ATA-specific technology, and it seems to be, but I don't know enough about SAS drives to say it's conclusive.

If it matters, I'm using an older SuperMicro chassis with a backplane connected to an HBA to clear them.

[bandit8623]

update here, drives doing same thing with same batch. ill hopefully have a log to share in the next few days. will that log show up where the certs normal go?

[PartialVolume]

Just to clarify, so you ran wipes on 16 drives that were not type 2 and they all wiped successfully without any errors. I think we need to format some SAS drives as type 2 and run our own tests and see if we can reproduce this.

[PartialVolume]

For reference, can you post the lspci output of the server that generates the I/O errors on type 2 formatted drives. Thanks.

[bandit8623]

they were completely diff models but yes. on the lspci output ill see what i can do. no longer have those drives in that system.

[PartialVolume]

The more I read about type 2 and Linux the more I just want to put a check in for a type 2 formatted drive that says reformat the drive without type 2 protection then wipe.

So type 2 formatted drives, also known as DIF/DIX (Data Integrity Field/Data Integrity Extension) and T10-DIF/DIX are all to do with 8 bytes of data are are associated with every block. So on disk a 512 block on disc occupies 520 bytes.

Having read a few documents and articles on this subject, there have been a few issues and it would seem there still are some issues about using this DIF/DIX protection on any Linux based system except one designed specifically for the purpose.

I've read (which may or may not be true) that ..

• No Linux file-system supports DIF/DIX which may be because Linux memory management doesn't support it if you are using cached I/O (default for Linux) BUT if your program uses DIRECT I/O then it should work as long as your driver supports DIF/DIX. This might be fixed in later versions of the kernel.
• mspt3sas apparently does support DIF/DIX but you have to enable it when the mspt3sas driver loads by appending mpt3sas.prot_mask=0x7f to the kernel command line. Which opens up a whole new set of questions when dealing with mixed discs like ShredOS/Nwipe does.
• Your HBA needs to support DIF/DIX and have the correct firmware.

How does all this affect ShredOS/Nwipe?

• Nwipe operates in cached I/O mode, DIRECT I/O is a feature I would like to add. Whether that is still an issue on a modern kernel I'm not sure. Apparently memory management can move cached I/O about in memory which can result in the wrong CRC being calculated against the wrong data (intermittently). This might explain how a minority of zero fill wipes succeeded while others failed but seemingly at random points in a wipe. If nwipe performed DIRECT I/O and managed it's own disk buffer, then once the buffer was dynamically allocated we wouldn't be moving it about or realloc'ed it.
• Nwipe or ShredOS would have to recognise a type 2 formatted drive then check the kernel command line for mpt3sas.prot_mask=0x7f and if not present, require the user to add the text and reboot. We would need to determine whether it was necessary to remove this for non type 2 disks?. If that is correct then it becomes a problem with a server that is wiping a mix of type 2 and standard SAS discs simultaneously. It would be nice if mpt3sas adopted the correct mode based on the disc, but then again, maybe it does and mpt3sas.prot_mask=0x7f is not necessary in a later version.
• How does this complicate things when nwipe is being run on a Linux distro that is not ShredOS, when your boot disk is non type 2 formatted.
• The T10-DIF/DIX apparently supports the application (or does it mean the mpt3sas driver generating the CRC for each block.

So we maybe have the following options:

• Add some code to nwipe that says the disk is type 2 formatted, reformat with type 0 protection and then wipe.
• Spend a lot of time trying to get ShredOS/nwipe to work reliably with type 2 formatted disks and possibly the other modes. If the kernel and driver handled all this then maybe there wouldn't be a problem.

Personally, I think there are more important features that need adding to ShredOS/nwipe first before working on this which seems fairly niche.

As always, your thoughts are appreciated and if there is anybody with the suitable programming skills that wanted to make this their pet project you are always welcome to submit a PR. However, bear in mind you will need a suitable DIF/DIX capable server and at least 20 DIF/DIX discs formatted with type 2 protection to be simultaneously wiped, in order to be sure there aren't any driver or memory management issues that might cause false I/O errors.

[bandit8623]

Great information.
I would say type 2 protectred drives are not the majority so what you say about working on other features makes total sense. maybe just a warning check on the drives? like wipe at own risk may not work?

i would agree features like direct i/o would be a higher priority than making type 2 work 100% of the time. I come accross alot of diff drives and types (sata sas hdd ssd) so if you need me to test something let me know.

as for the mpt3sas my systems i was using are using a mptsas2 cards latest firm. LSI 9206-16e 6Gb/s 16-Port SATA SAS PCI-e 3.0 x8 External HBA SAS2308- firm 20.00.07.00
since the program killdisk likely uses direct i/o (uses like 5gig ram when wiping 80 drives) that finishes fine so im thinking the cached i/o may be the ticket. with direct i/o much less cpu usage as well.

let me know if i can help further.

[PartialVolume]

@kevin-bbinc

Forgive my ignorance, but is it possible that this affects SAS drives specifically? I recently cleared 8 drives, 1 SATA and 7 SAS, and the SATA drive cleared as expected without any warnings in the report. I googled if HPA/DCO is an ATA-specific technology, and it seems to be, but I don't know enough about SAS drives to say it's conclusive.

The SAS drives we test with don't support DCO/HPA, hence the [HS? ???] Status response, however it possible some drives do, although at the moment we don't know which models those are or even if they exist. SAS drives do use the ata command set as used by SATA drives however they don't necessarily support all commands including those to retrieve the HPA/DCO status, so theoretically
they could support HPA/DCO. However, HPA/DCO is or has been dropped by Seagate on some enterprise drives or so I believe so it's quite normal to not be able to determine the HPA/DCO status as the drive doesn't respond to the commands or if it does responds with invalid data.

[kevin-bbinc]

Gotcha. I appreciate the explanation!

[de47110815]

Hello,

it is quite interesting, I experienced similar behaviour. Before I give you more specific answer, can you answer following questions please?

1. Assuming by serial number, these drives should have an OEM label from Dell, is there an other part number on it?
2. You mix SATA and SAS drives during one run on the same controller, correct?
3. Have you tried the same run only with one drive that causes this problem on the same system?
4. Are you sure, that these drives does are not soft RAID members and OS is trying to reorganize them in the background? Linux Mint needs a lot of changes different from the default config in order for nwipe to run undisturbed. (automount, fwupd, indexing, zfs deamon, energy saving/sleep modes etc.)
5. Do you use a swap partition and how memory, swap and cache develops during the run?
6. Which Killdisk version do you use?

regards
BS

[bandit8623]

Hello,

it is quite interesting, I experienced similar behaviour. Before I give you more specific answer, can you answer following questions please?

1. Assuming by serial number, these drives should have an OEM label from Dell, is there an other part number on it?
2. You mix SATA and SAS drives during one run on the same controller, correct?
3. Have you tried the same run only with one drive that causes this problem on the same system?
4. Are you sure, that these drives does are not soft RAID members and OS is trying to reorganize them in the background? Linux Mint needs a lot of changes different from the default config in order for nwipe to run undisturbed. (automount, fwupd, indexing, zfs deamon, energy saving/sleep modes etc.)
5. Do you use a swap partition and how memory, swap and cache develops during the run?
6. Which Killdisk version do you use?

regards BS

its been awhile now.
1- the drives i was using were not oem just straight seagate
2- was not mixed
3- yes worked fine
4-yes no raid. besides running killdiskl deletes that information as well. have tested leaving raid information on drivbes after being wiped they no longer have that info
5- i dont know about swap but it used a ton of ram and cpu.
6-latest ide have to get version at some point.

[bandit8623]

killdisk 6.0.11

[FreeMinded]

@PartialVolume I just finished testing nwipe v0.37 with the PDF feature (which I absolutely love!). I have 9 out of 10 drives giving the HPA/DCO warning. Out of them 4 SAS all gave the warning, only one SATA drive did not.
I have the same "issue" as @thebearnecessities and @kevin-bbinc with the warnings on the report triggering questions from customers. Is there already an idea how this could be handled without "scarring" customers? Maybe an option to not handle the HPA/DCO Unknown as a warning?

If there is a way I can contribute to improve this feature I happily help. (i.e I have quite a few drives (SAS and SATA) waiting for erasure and can provide more details if that helps.)

BTW: would it be possible to add the SMART self-check result to the first page under Disk information? The two smart pages with details are great but having the status on the first page would help to quickly see if a device is still good for use or not.

[PartialVolume]

Exactly 👍

[FreeMinded]

@PartialVolume here the definite confirmation... the SAS controller supports HPA/DCO.
nwipe_log_batch-7.txt

[PartialVolume]

Just to confirm something. Is /dev/SDA connected to SAS or a SATA interface? I was sort of expecting the transport to say SAS but maybe it's recognised as ATA when it's a SATA drive even though it's connected to a SAS interface.

[PartialVolume]

In terms of the program logic I'll modify it so that if HPA and DCO identify fails and the transport is SAS it will assume therefore that HPA and DCO are not supported and will therefore report no hidden sectors.

I'm just thinking about how you might be able to test this patch for me.

Do you have a disc on this server loaded with Ubuntu whereby you could build the nwipe master and test SAS says HS=no

Or

Do you want me to provide a ShredOS .img with the changes that you can just burn to a USB and test SAS drives report HS = No.

[FreeMinded]

@PartialVolume all the drives shown in the batch-7 screenshot are connected to the SAS controller. The device naming on this system doesn't seem to make a difference between SAS and SATA.

Regarding the testing I would prefer a ShredOS image.

[PartialVolume]

Referring back to your first comment

with the warnings on the report triggering questions from customers. Is there already an idea how this could be handled without "scarring" customers?

For the drives that report HPA/DCO warnings, I think we need to determine whether the warnings were caused by a HPA/DCO status of ??? because the drive wasn't responding to the commands to determine DCO or whether nwipe did indeed detect a hidden block/s in which case the DCO and HPA status would have said yes, in which case the drives HPA/DCO should be cleared using hdparm or other tools so the whole of the drive can be fully wiped. That would be the appropriate action first before wiping the drive.

[PartialVolume]

Thinking about a HPA/DCO status that can not be determined due to either the drive not supporting DCO or the interface not supporting ATA pass through, which then results in a PDF report that says erased but with a warning.. Maybe under that circumstance I could put a option in the configuration that allows the user to generate a report without the warning and exclamation icon on the report, but instead simply says erased and in the HPA/DCO field just says "HPA/DCO check disabled by user". I'm guessing though that an inquisitive customer might ask why HPA/DCO was disabled by the user and what's the significance of disabling HPA/DCO checks.

The problem is you could also have a drive with a hidden area that can't be detected if the interface doesn't support ATA pass through, like a lot of USB adapters. The report needs to issue a warning in this case, because it physically can't check the HPA/DCO status unless its connected to an interface that does allow ATA pass through.

I'm concerned that if nwipe had an option that completely disabled HPA/DCO checks and there was a hidden area that contained who knows what, the report in that circumstance should not show that the drive had been fully erased when in fact there was this hidden area that hadn't been wiped. That wouldn't look good.

SAS is problematic for me as I don't know whether most SAS drives supports HPA/DCO like their SATA cousins. In theory I should be able to issue a device identify command and check whether DCO is supported. If not then I might be able to set the HPA/DCO status as no hidden areas assuming HPA also is not allowed.

What I need is nwipe -q -v --logfile=log.txt` logs of lots of different SAS drives with different controllers so I can see how they are responding at a low level.

Any comments are always appreciated.

[PartialVolume]

I can see that the SAS drives are not responding to the hdparm request or nwipes built in low level code for DCO identify etc.

This maybe because they don't support the ATA commands, maybe just SCSI commands.

I'll see if I can get hold of a programming manual for these 12TB Seagate SAS drives. It's possible they don't support HPA/DCO or AMA (host protected area/drive configuration overlay or Accessible maximum address) as they only communicate using the SCSI command set. I need to do a little research. If anybody understands these SAS drives in terms of low level commands or has any sources of information, please let me know. In the meantime I'll see what I can figure out.

[PartialVolume]

I must admit I do really like Seagate's documentation. Some other manufacturers can be really lacking but I always find Seagate provides plenty of information in their product manuals. Anyway at first glance it looks like I'm going to have to add a function that issues a SCSI device identification command and if I get sensible data and no illegal requests that may be enough to provide a status of 'no hidden area' as the SCSI commands make no mention of HPA/DCO/AMA.

100828039c.pdf

[PartialVolume]

Committed SAS HPA/DCO patch martijnvanbrummelen/nwipe@8a93e88

@FreeMinded I'll build ShredOS with this update and provide you with a download link ASAP.

[PartialVolume]

Excellent, that change will be in the next official release.

On a different subject. Drive sdd is showing 0 degrees C in the snapshots above. Is there something wrong with the drives temperature sensing? All your other drives temperatures look good.

[PartialVolume]

@FreeMinded Are the PDFs for those SAS drives that show [HS? N/A] also looking good, i.e. no warning exclamation, just a solid green tick in the top right corner and the hidden sector fields just show Not Applicable?

[FreeMinded]

@PartialVolume That 0C drive is kind of broken (and the reason why I used it in this test batch).
The PDF looks good for the SAS drives! You can go ahead an ship it. 😃 Thanks a lot for your work!

nwipe_report_2024-09-16-14-05-21_Model_HP_EF0300FATFD_Serial_J0XJ9NMS.pdf

[PartialVolume]

😃 Thanks a lot for your work!

It's a pleasure and thank you for your feedback and help especially as I don't have any SAS hardware which makes your work testing this invaluable.

[danielor10]

Hello! @PartialVolume i'm experiencing the same problem with all the SAS Disks i have tried on our Lab. If be of any help, we can help testing your changes to.

[FreeMinded]

As a side note: I have rerun the same drives from the very first batch (#234 (comment)) over and over again. The HPA/DCO detection issue disappeared and the drives wiped OK (all green in the PDF) and except for one drive which seems to be somehow broken.
Not sure why that is but it might help to just rewipe drives with HPA/DCO issues again. 🤷‍♂️

[Firminator]

Instead of "Not applicable" or "HPA/DCO check disabled by user" it could say
"Not supported by drive and/or controller"
which ultimately would show the customer what's going on and takes the blame off nwipe or the user/technician.

[PartialVolume]

Instead of "Not applicable" or "HPA/DCO check disabled by user" it could say
"Not supported by drive and/or controller"

I like "Not supported by drive and/or controller". Assuming the text isn't too long to fit in the field.

[FreeMinded]

@PartialVolume there is a big difference between "Not supported by drive" and "Not supported by controller"! I wouldn't mix those two. In the first case you can safely assume there are no hidden sectors. In the second case you simply don't know.

[PartialVolume]

Good point. As is the case with USB where ATA pass through may or may not support ATA pass through to allow interrogation of the drive. So in that case and as it currently is for USB unless I get valid data i.e a yes or no then I have to put ???? As HPA status as I can't be sure the controller is blocking access.

With SAS I currently believe I'm correct in saying (correct me if I'm wrong) that the SCSI command set used by a SAS drive knows nothing about HPA/DCO. Those commands just don't exist in the SCSI command lists, hence why if bus = SAS it should say either Not applicable or not supported by drive.

HPA status currently
For SAS then is now only one outcome. Not applicable.

For SATA 3 outcomes
Yes
No
Unknown

For USB
Yes
No
Unknown

For nvme
Not applicable

For MMC
Not applicable

[Firminator]

or could this be caused by smartctl not supporting it?

[PartialVolume]

Smartctl isn't used to detect HPA/DCO. That's done by a combination of low level ioctl commands directly to the drive that nwipe does, also hdparm and libata. It then assesses the results from all three and makes a decision based on the result.

[Firminator]

or add a new Disk Information item called 'HPA/DCO Status':

Make/Model: HP EF0300FATFD                   Serial: J0XJ9NMS
Size(Apparent): 300 GB, 300000000000 bytes   Bus: SAS
Size(Real): 300 GB, 300000000000 bytes       HPA/DCO Status: Unsupported by drive and/or controller

and if nwipe finds its unsupported remove the 2 items
HPA/DCO: Not Applicable HPA/DCO Size: Not Applicable
from the Disk Erasure Details section as they become redundant due to HPA/DCO not supported. This way we don't have superfluous/not applicable/useless information in the report.

If 'HPA/DCO Status' is supported then keep the 2 items with whatever variables you have them populated.
HPA/DCO: Active HPA/DCO Size: 1MB

[PartialVolume]

I like that too.

[de47110815]

it could be caused by using a card not supporting smartctl like HP P822.

…

Firminator ***@***.***> hat am 17.09.2024 05:11 CEST geschrieben: or could this be caused by smartctl not supporting it? -- Reply to this email directly or view it on GitHub: #234 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[PartialVolume]

See comment above about smartctl not being used to detect HPA/DCO. If HP P822 does not support smartctl, the following should happen, with the new code if bus is detected as SAS the report will say HPA/DCO is N/A. Smart data on page 2/3 will be missing. However if the controller works fine with smartctl then HPA/DCO will still be reported as N/A due to bus = SAS and smart data will be present. If a SATA drive is plugged into a SAS interface the bus should be recognised as SATA and not SAS. Bus recognition is done by libata.

[FreeMinded]

@PartialVolume is there an ETA for the next release containing this changes?

[PartialVolume]

@FreeMinded I try to release at 6 months intervals or earlier so the last release was May so I'm probably looking at mid November. I also want to get the additional host specific PDF option included in that release.

[PartialVolume]

I was referring to nwipe for the 6 month release cycle. A new version of ShredOS with the latest nwipe will follow within a few weeks of the nwipe release.

[FreeMinded]

@PartialVolume any update on the ETA of the next release?

[FreeMinded]

@PartialVolume ping

[FreeMinded]

Thanks for the Release! @PartialVolume

[de47110815]

Hello,

some of my remarks:

1. do not mix PI protection Information field or type 2 formatted disks with not protected during a wipe is one idea
2. adding mpt3sas.prot_mask=0x7f to the kernel command line is buggy
3. when you use instead a card that utilizes mpt2sas, are you able to wipe type 2 formatted disks with no problems?
4. have you tried removing type 2 protection with "scsi_ch_swp -s 0 -v -w /dev/sdx"?
5. can you post the output from "dmesg -w" for the part where your system recognizes the drive which causes problems?
6. have you removed all partitions prior to wiping?
7. are the drives a part of an RAID array, any type, zfs or whatever and your system tries to rebuild it? have you deactivated such functionality?
8. what is the output of sg_modes and sg_readcap for the drive?
9. in some cases, nwipe shows the error -1, but the disk has been wiped, the error comes in the moment of writing the last sector.
10. broken drive or even mixing slower and faster drives or HDDs with SSDs can cause the error -1 due to timeouts on hangs on the bus/lane
11. wiping more than 500 or 1000 disks on one machine locally over SAS causes glitches on console running nwipe, maybe the errors are connected to this. But I also wiped more than 2000 disks at once successfully, CPU should not be over 90%, trying to play with nice values is not really nice as it should do the job with defaults

regards

[PartialVolume]

wiping more than 500 or 1000 disks on one machine locally over SAS causes glitches on console running nwipe, maybe the errors are connected to this. But I also wiped more than 2000 disks at once successfully, CPU should not be over 90%, trying to play with nice values is not really nice as it should do the job with defaults

2000 drives simultaneously has got to be a record. I've never seen more the 50 simultaneously wiped. That has to be some serious hardware.

[bandit8623]

sg_format I'm assuming you use the format command to wipe the drive although I'm not sure whether it's actually writing every bit in a block or just reformatting the blocks header. The man page doesn't seem to go into detail on that.

I reached out to @doug-gilbert here, maybe we get a response. Afterwards I can update the SG man pages with a PR.

from my testing it writes every block. it takes a long time. usually 1tb an hour for standard sas drives.. longer for sata. sas SSD's are fairly quick.

[de47110815]

sg_format works with SAS only. The sg_format utility is specifically designed for SCSI/SAS drives and uses the SCSI FORMAT UNIT command. It is not directly compatible with standard SATA drives, as SATA drives use a different command set (ATA) and do not support the SCSI FORMAT UNIT command. For SATA drives, you would typically use tools like hdparm with the SECURITY ERASE UNIT command instead of sg_format.
However, if you are using a SAS controller that supports SATA drives (via SATA Tunneled Protocol), you may be able to use sg_format on SATA drives connected to a SAS HBA, but this is not guaranteed to work on all SATA drives and depends on the controller and drive compatibility. Never used it for those. WHat is your setup when you use sg_format on SATA drives?

[de47110815]

it writes every block that is available, so you might need to get access to more blocks before using that command

[bandit8623]

sg_format works with SAS only. The sg_format utility is specifically designed for SCSI/SAS drives and uses the SCSI FORMAT UNIT command. It is not directly compatible with standard SATA drives, as SATA drives use a different command set (ATA) and do not support the SCSI FORMAT UNIT command. For SATA drives, you would typically use tools like hdparm with the SECURITY ERASE UNIT command instead of sg_format. However, if you are using a SAS controller that supports SATA drives (via SATA Tunneled Protocol), you may be able to use sg_format on SATA drives connected to a SAS HBA, but this is not guaranteed to work on all SATA drives and depends on the controller and drive compatibility. Never used it for those. WHat is your setup when you use sg_format on SATA drives?

correct! sas hba's like 3008 or 2208 or 2308 in it mode. sata ssd's never work.
sorry i did not specify enterprise cards/backplanes

[de47110815]

For SATA SSDs you can try to use sg_sanitize --block --quick in first run, then second run with sg_sanitize --crypto --quick which we run twice. Monitor progress in your script with sg_requests like g_requests --num=9999 --progress "$d", hard coded number will not be even reached and works here better than sg_turs. The SCSI to ATA Translation (SAT) definition for the SCSI SANITIZE command appeared in the SAT-3 revision 4 draft. This works for enterprise SATA SSDs running in external enclosures. What else is important, is the driver you use. I prefer to start with mpt3sas driven HBAs as they have more features and bandwidth, but I have also mpt2sas driven HBAs and also some other which use other drivers. Depends on what you wipe on which enclosures. If you struggle with type 2(3) protected disks, SCSI DIF/DIX T10 standard for Data Integrity Field, which was the question here, mpt3sas and mpt2sas pass through PI to the OS and enforce PI validation, you have to disable PI with scsi_ch_swp -s 0 -v -w, which works correct under mpt3sas, but under mpt2sas you have to patch your kernel before you can use it. Which I tried few times, and never really worked, because of incompatibilities of dependencys of the older patch files and likely current kernels. And this BTW works only when your SAS target drive has been recognized by the system, so lets keep it short and lets say it has a supported block size, of 512 bytes lets say. If you have a 520 bs drive with type 2 prot seen by OS with capacity 0 under mpt2sas you could patch the kernel blocksize first then apply second patch for correct PI handling sure you will have much fun with that. It almost comes down to build linux from scratch. In such cases you are forced to use vendor specific tools, which are not always available or will fail on specific firmware revisions, especially on the enterprise drives with custom firmware made by NetApp, emc, ThinkStorage, DDN, etc. Many manufacturers do not offer the wipe function in their directors anymore, they have patched it out, either completely than hidden and they offer the wipe as a service where you pay like 50k to wipe a rack. If you are lucky and still have the host hardware, you can easily wipe such disks, for example IBM disks with 528 bs on a Power8 machines, because you will be able to set the integrated RAID controller to HBA mode, install Ubuntu 20.04 LTS on such machine on 1 drive and all disks in other slots will be presented to you with blocksize 512, as the controller drivers are doing the job, I have done this it worked fine and the compatibility with supported drive models was way beyond the official FRU list. So back to the hard stone again, wiping any PI protected SAS disks with unsupported block size that show up with 0 byte capacity on any Linux machine - the problem is only that when we write only 512 bytes into each block, the 8 bytes meta remain which in theory is not 100% wiped. The drive will not have more smaller sectors after this operation. So either you can accept that, especially if you comply on a very low treshold for remapped sectors or even zero, and the new owner will immediately reinitialize them in his system which supports block size of 520 or 528 bytes. Or you know the trick how to do this, which requires only 2 things - more than 1 run and something that you already read in this post. Or maybe I am doing it wrong and there is a simpler solution happy to hear about that.