1. The log reported verification errors while also
showing an entry in the log that said "[SUCCESS] Blanked /dev/...".
The blanked device message now shows [FAILURE] /dev/... may not be blanked"
if any verification errors are detected for a specific drive.
2. If a verification error occurred, the error would be correctly
shown in the GUI and in the logs but the summary table drive status
would show 'ERASED' not 'FAILED'. Now corrected so that the tables
drive status field shows 'FAILED' if any verification error is detected.
Prior to this it was marking the status as 'FAILED' only if the O.S
detected write errors. In practise most drive errors are detected
by the write I/O process on syncing but this will now detect errors not
recognised by the O.S. and found by the verification process. Despite
this the textual log and GUI correcty reported verification errors.
3. The final log message "Nwipe exited successfully" was checking for
fatal errors but ignoring non fatal errors despite being reported in
the log.
The final message now reads
either "Nwipe Exited Succesfully" if no fatal and non fatal errors were
detected. Alternatively it displays ...
"Nwipe exited with errors, check the log & summary table for individual drive status."
if any fatal OR non fatal errors are detected.
Add a summary table to the log that shows each drives status
i.e. erased or failed, throughput, duration of wipe, model,
serial no etc. In particular it benefits those that wipe many
drives simultaneously in rack servers. At a glance any failed
drives can be seen without having to browse back through the
log. Especially useful in --nogui mode, but also useful in GUI
mode.
1. Keep nwipe_log notices succinct and below 80 chars in length including
timestamp. This is especially relevant for 80x30 terminal use such
as ALT-F2 etc or Shredos without losing any information.
2. Add [SUCCESS] to blanked & verified messages to make them stand out for quicker checking.
I could not find the original specification of this standard, although
many proprietary implementations exist (or claim to exist). Also there
are many 3rd-party descriptions of the method, which often differ in one
or another detail, but after some reading I could conclude that the most
likely definition should be as follows:
1. Fill the device with zeroes, do not verify.
2. Fill the device with ones, do not verify.
3. Fill the device with a PRNG stream, do verify.
In other words, this is a simplified version of nwipe's "dodshort".
Symptoms: If you control-C to exit nwipe at the end of a successful
wipe you would get a segmentation fault. If nwipe log data was being
sent to stdout rather than to a log file, then you would not see the
log in the terminal windows after nwipe had exited. This patch fixes
those problems by creating a tri-state wipe flag for each wipe
thread. The main thread after having launched the wipe threads
will wait for ALL wipe flags to report that the wipe routine has
completed and the thread has exited. Only at that time does the
main() routine then proceed with joining the threads and waiting
for the join to confirm the thread has indeed exited. This join
is important as the thread will not actually exit until the OS
has flushed the disk buffers. Currently nwipe does not use O_SYNC
where data is sent straight to disk. Therefore it's important
to wait for data to be flushed before exiting nwipe. Part of this
patch is introducing a "please wait .. disks are being flushed"
prior to exiting nwipe otherwise it might look like nwipe had
hung. A disk flush in terms of how long it takes, can be from
instantly to 30 seconds or more, depending on how much system
memory you have, when the last sync occurred and if you have
changed the sync option from it's default. Something else to
note is that when all wipes have finished nwipe displays "Enter
To Exit" on the status line at the bottom of the screen. I
believe typing 'enter' rather than control-c did not produce a
segmentation fault. Irrespective, both methods of exiting nwipe
have been tested and confirmed to now work correctly. Tested
overnight with two drives using multiple wipe methods,
verification and blanking.
