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

[thebearnecessities]

We got this warning from three out of a batch of 6 we were wiping.

But to be fair, we hadn't seen it for the previous 20 devices we ran nwipe on.

We are running the latest version of nwipe (that from memory was released last November-ish?).

Quick background, we are a charity in Scotland, UK that is taking laptops from local businesses and wiping the hard disks and then refurbishing the laptops for good causes.

So when I send the reports to the businesses to reassure them that their data has been written over successfully, the exclamation marks and large red warning text is gonna spook them, lol

My basic understanding is that this HPA/DCO hidden sector is not used by the OS to store any user data, so it is not any type of security issue. But that was just from a quick Google as I had never heard of HPA/DCO sectors before.

Loving your software, it's helped our charity a lot, because we don't have any budget for blancco or similar.

Is there a way we can make a donation for your efforts?

[PartialVolume]

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

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

[PartialVolume]

One issue that nwipe might have with using a single prng calculation is how to deal with drives that are substantially running at different speeds, you could have a a prng window of say a 1 GByte but the fastest drives would have to wait for the slowest drives to catch up if their speed meant they fell outside the window PRNG buffer. Probably not a problem if all your drives are pretty much all running at the same speed.

[fthobe]

Can I hot swap disks while others are in process? I have never tried that.

[PartialVolume]

No, that has been asked for before, but I've never got round to doing anything about it.

[de47110815]

Indeed, this is little tricky function. There are several ways to solve this. If all drives run at pretty the same speed there is no problem. If not, you can just chunk the checksum of the fastest drive at a point which equals the capacity of the slower drive. The PRNG buffer could overflow, if you can not cache it properly. If your RAM is bigger than the largest disk, this would not be a problem, but this is not the path you wanna go. In fact the solution is you can simply use a mix of pattern and random to write random pattern and repeat this. Most simple way is to generate a random pattern of a block size and to repeat it times number of blocks. But for some customers this is not enough. I always do not understand why patterns at NetApp or EMC or wherever contain three or five or whatever few characters. Feel free to adopt this with possibly any size you can calculate for the current batch, that matches all drives in current run in a way that the free chosen size of the multiplied PRNG chunk, which should be at least block size up to anything useful equals exactly the capacity of the drives within the run. If, with any size you like to go with (should of course be smaller than smallest disk), some tail remains on some disks, you just calculate the "tail" and add this chunk to hash. In this way you need to, hash the repeating block, count ammount of these and if not even add the tail to the hash for each disk to get your hash for each of them. You can have the hash calculation even ready before writing everything to a device, so you can start verify of the fastest ones immediately and the slower ones will follow. The standard PRNG block size can be either a static value (as I mentioned between one block and size of the smallest disk) or some kind of dynamic value, like half of the RAM or whatever. This is just one solution, you can also run full PRNG and watch your buffer, on a treshold pause generating PRNG and copy from the fastest disk to the slower ones, using the fastest drive as buffer, and resume under treshold. Running pre check to determine writing speed allows you to calculate treshold values. You should also consider to include memory capacity into this calculation, in order to give high mem configs an advantage. Just some ideas for your code.

[fthobe]

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.