The format specifier didn't match the size of the variable that holds
c2[i]->device_sector_size which is an int. This didn't appear to cause
a problem with reporting in a 64 bit build. It does cause a problem in
a 32 bit build displaying a very large & incorrect number for sector,
block and device sizes.
This doesn't cause any issues with the overall function, simply
incorrect sector, block and device sizes in 32 bit builds as displayed
in the nwipe log.
I also changed the signed long long for c2[i]->device _size to a
unsigned long long as there is little point in a negative device size.
Add /sys/class/hwmon/hwmonX/device/ to the list
of directories to search for a given device.
Some nvme devices/controllers put the device name
in /sys/class/hwmon/hwmonX/device/ rather than
/sys/class/hwmon/hwmonX/device/nvme/nvme0/
Update debug messaging.
For sdX devices we look in
/sys/class/hwmon/hwmonX/block for the device
name.
However, for nvme we access the device name
by looking in ..
/sys/class/hwmon/hwmonX/device/nvme/nvme0
nvme0n1
Multiple nvme drives/controllers will need
to be tested.
In the drive selection window when you
select a drive, the drive is identified
as selected for wiping with the [wipe]
label, however if you then select a
verify only method such as 'verify with
ones' or 'verify with zeros' it still
says [wipe] which is technically a
contradiction.
This patch changes the [wipe] to a
[vrfy] when a verify only method is
selected. If a method is selected
that writes data to the disc then the
label is displayed as [wipe].
If a faulty drive fails mid wipe and it's
throughput drops until eventually reaching
zero. The ETA calculation grows to an enormously
high value.
This patch prevents the ETA being calculated if
the throughput for a given drive drops below
100,000 bytes per second. In this way we can still
see that something is wrong because the ETA is much
higher than normal but prevents the sort of calculation
that looks like this ! 90867213:29:12 i.e ..
90,867,213 hours, 29 minutes and 12 seconds, or put
another way, 3,786,133 days or 10,372 years.
When many verification or pass errors are detected
the status line can wrap on a 80 column display.
This patch makes the error message more succinct
which will free up about 10 characters & prevents
the line wrapping.
If you used control-c during a wipe,
the summary table would report FAILED
rather than UABORTED, even though no
errors had occured and no errors were
reported in the error summary table.
The correct message on control-c abort
should be UABORTED if no errors on that
drive had so far been detected or FAILED
if errors had been detected.
nwipe reported correctly when letting
the wipe continue to it's natural completion.
This patch fixes that issue.
Anonymize the serial numbers in the gui, the
log and the summary table.
If a serial number was obtained from the device,
it is replaced with "XXXXXXXXXXXXXXX".
If the serial number could not be obtained from the
device, it's replaced with "???????????????".
This fixes column alignment issues in the gui
with nvme drives i.e. nvme0n1 etc. If the drive
name including path exceeds 8 characters the
/dev/ is removed and prefixed with spaces to
a total max length of 8 characters.
In both selection and wipe status windows I
moved the temperature readout to the right
of the disk size column.
Also in the wipe status window, by moving to
the right of the disk size column the
temperature is no longer on the same line as
the disk pass progress. This reduces the line
length as I found that in tests if you had
many verification errors the temperature
being on the end of the line would disappear
of the right of the screen.
Also removed 1. 2. etc from drive selection
to reduce the line length. Also removed the
space between > and [, ie "> [wipe]" becomes
">[wipe]" These changes remove 3 characters
and help to reduce the affect of the additional
temperature field [30C] which add 5 characters.
Therefore the line length overall, increased by
5-3 = 2 characters.
This helps to reduce line wrapping on 80
character terminals, when the drive model length
exceeds 24 characters.
1. Changed a few nwipe log messages to improve
readability.
2. Added code so that the temperature changes from
- white text = (Temperature within spec)
- red text = max continuous temp reached
- red flashing text = critical upper temperature reached
- black text = minimum continuous temperature reached
- black flashing text = critical lower temperature reached.
1. Changed gui format specifier to match signed
integer that we changed to in the previous commit.
2. Changed the format specifier in verbose nwipe logging of
the temperatures and moved the nwipe log message that prints
the hwmonX path to the log in order to remove
unnecessary printing to the log.
1. Changed u64 to int to support negative
temperature values, i.e. temp1_lcrit may
be as low as -40C
2. In gui surround temperature reading with
square brackets instead of round brackets to
be consistent with the rest of the drive status line
Stage 2 modifies the GUI to trigger a temperature
update every 60 seconds. Changes were made to the
drive progress line to include [ 30C ]. The drive
context structure had another variable added that
records the time of the temperature update.
Note. When the temperature data cannot be retrieved
from the hwmon (drivetemp) module the GUI displays
[ --C ]. USB devices, even those adapters that support
ATA pass through, don't seem to work with hwmon (drivetemp),
at least the adapters I have don't work with drivetemp
to monitor temperature.
Stage 1 adds the additional variables to the drive
context and creates the temperature initialisation
function, which associates a hwmonX directory with
a block device. Also wrote the context update function,
that reads hwmon for each drive context and writes the
temperatures back to the context.
Stage 2 commit to follow which will make changes within
the GUI to call the update function every 60 seconds
and display the temperature information.
For some controllers/drivers the readlink method of
obtaining the bus type for GUI display does not work.
If we haven't already resolved the bus type, we then
also check smartctl for the transport protocol
for SATA.
