Feature Request: show temperature

[Firminator]

For NVMe:

the NVMe HWMON support to allow reporting the current NVMe drive temperature sensor(s) and min/max thresholds via this kernel infrastructure. This in turn allows user-space to simply query the data over sysfs without the need for any utilities, no root requirement, and should gracefully work with the various programs that report HWMON sensor readings to Linux desktop users.

source https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-NVMe-HWMON-Support

• possible since 5.5 kernel (current ShredOS runs 5.6.3)
• grep . /sys/class/nvme/nvme0/device/hwmon/hwmon[1-9]/{name,temp1_input} The number 1 to 9 probably depends on the mainboard/device and will list temperatures from other devices as well. Example on my box: cat /sys/class/nvme/nvme0/device/hwmon/hwmon3/temp1_input The value that it spits out (e.g. 31850] needs to be divided by 1000 for human readable format, i.e. 31.85 Celsius
• or use nvme-cli: nvme smart-log /dev/nvme0 | grep -i '^temperature'

For SATA:

• should be build into kernel; background info @ https://lkml.org/lkml/2019/12/9/9
• grep . /sys/class/hwmon/hwmon[1-9]/{name,temp1_input}
• ShredOS doesn't come 'sensors' and grep /sys/class/hwmon/ doesn't work
• hence might need to use https://www.kernel.org/doc/html/latest/hwmon/drivetemp.html

[Firminator]

since we have already smartmontools present in ShredOS the following commands could be used as fallback in case drivetemp doesn't deliver... NVMe: smartctl -A /dev/nvme0 | grep -i temperature | awk '{print $2,$3}' SAS: smartctl -A /dev/sdX | grep -i 'current drive temperature' | awk '{print $4,$5}' SATA: smartctl -x /dev/sdX | grep -i '^194' | awk '{print $8}'

[PartialVolume]

Thanks for that info, saves me a lot of time and should be quick to implement. In fact after adding the code so SATA shows up on your controller as well as SAS, I think I'll add these next. I would think an update interval of 20 seconds should be sufficient? I wouldn't have thought the drive temperature changes too fast. Maybe even once a minute.

[Firminator]

Minute should be fine until proven otherwise :)

I'd think that drivetemp would be the prefered first way as it's agnostic and doesn't rely on 3rd-party tools. Since it's using common ATA commands it should cover IDE, SATA, SAS and possibly even NVMe drives. As a fallback it will readout the temperature from SMART accd. to their documentation:

"If supported, it uses the ATA SCT Command Transport feature to read the current drive temperature and, if available, temperature limits as well as historic minimum and maximum temperatures. If SCT Command Transport is not supported, the driver uses SMART attributes to read the drive temperature."

The temperature is SMART attribute 194 btw. Some (a lot) (of older) drives don't have that attribute, or the FW has it implemented wrong or some other other odd reason out of our control, so even that can fail. If that fails then even smartctl/smartmontools or other 3rd party tools will ALSO not be able to tell you the temp.

[PartialVolume]

Drivetemp it is, I'll leave this link here as a reminder https://www.kernel.org/doc/html/latest/hwmon/drivetemp.html for next week

[Firminator]

If there is GUI space I'd would like to see something like this (using the WD drive in your screenshot): 2. /dev/sdb SATA-2 (3.0 GBit/s) (2 TB) (33 C)

[Firminator]

Just some work notes

• hddtemp is 3rd-party and can be deprecated at some point. also needs sudo.
• rather get temperature from user space with the help of drivetemp kernel module available in kernel 5.6 or later. uses kernel API hwmon so temp is returned with sensors tool.

Sample output for sensors

$ sensors
drivetemp-scsi-0-0
Adapter: SCSI adapter
temp1:        +31.0°C  (low  =  +0.0°C, high = +70.0°C)
                       (crit low =  -5.0°C, crit = +75.0°C)
                       (lowest = +28.0°C, highest = +38.0°C)

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +27.8°C  (crit = +106.0°C)
temp2:        +29.8°C  (crit = +106.0°C)

drivetemp-scsi-1-0
Adapter: SCSI adapter
temp1:        +31.0°C  (low  =  +0.0°C, high = +70.0°C)
                       (crit low =  -5.0°C, crit = +75.0°C)
                       (lowest = +28.0°C, highest = +37.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +42.0°C  (high = +85.0°C, crit = +105.0°C)
Core 0:        +41.0°C  (high = +85.0°C, crit = +105.0°C)
Core 1:        +41.0°C  (high = +85.0°C, crit = +105.0°C)
Core 2:        +42.0°C  (high = +85.0°C, crit = +105.0°C)
Core 3:        +41.0°C  (high = +85.0°C, crit = +105.0°C)

nvme-pci-0200
Adapter: PCI adapter
Composite:    +32.9°C 

drivetemp-scsi-0-0 and drivetemp-scsi-1-0 are actually SATA SSDs hooked up to onboard SATA ports. Adapter: ISA adapter is a 4-core CPU nvme-pci-0200 is a NVMe PCIe SSD drive

[Firminator]

cross-reference https://github.com/martijnvanbrummelen/nwipe/issues/290

[PartialVolume]

Temperature feature currently being written: Hopefully I will have a version ready for testing by the end of this week.

[Firminator]

Nice. Looking forward to it. Thanks so much.

[PartialVolume]

Here's a few screenshots from the first working version. Below are three screenshots showing the temperature rise after 15 minutes. The ambient room temperature during this wipe is 17.5C with the side taken off the PC. Must admit I was surprised how the drive temperature increased by 10C after 15 minutes and it's not like this room is particularly warm. I believe the max and critical temperatures for this drive are 55C and 60C (I need to check the log). The nwipe -v option shows all available temperatures for the drive including:..

temp1_input     Current drive temperature
temp1_lcrit     Minimum temperature limit. Operating the device below
            this temperature may cause physical damage to the
            device.
temp1_min       Minimum recommended continuous operating limit
temp1_max       Maximum recommended continuous operating temperature
temp1_crit      Maximum temperature limit. Operating the device above
            this temperature may cause physical damage to the
            device.
temp1_lowest        Minimum temperature seen this power cycle
temp1_highest       Maximum temperature seen this power cycle

(from [https://github.com/groeck/drivetemp](https://github.com/groeck/drivetemp)

I've got a couple of additional changes to make:

1. Change those ( 30C ) round brackets to square [ 30C ] to be consistent with the rest of the line.
2. Add additional code that changes the color of the temperature to RED once MAX temperature is reached than flash the temperature when critical is reached. As mentioned above Operating the device above this temperature may cause physical damage to the device.

[PartialVolume]

Now at 51C, just goes to show, if the ambient room temperature was closer to 30C, that disk may be operating at 60C. This Dell optiflex has no specific cooling for the disks and also the side of the PC is off so that will affect the airflow. Having the temperature reported by nwipe seems to be quite a useful feature to have.

[PartialVolume]

A couple of other things that I've noticed.

1. hwmon drivetemp doesn't appear to work with SATA discs attached via a USB/SATA adapter, even if that adapter is known to have a chipset that supports ATA pass through. I've left a message with the developer of drivetemp in regards to this. If drivetemp can't implement USB/SATA support for adapters that use a chipset that supports ATA pass through then I'll need to investigate other methods to retrieve temperature information from USB devices that run along side or in addition to drivetemp. When a temperature can't be obtained [ --C ] is displayed.
2. I've found my SanDisk 500 GB SSD does provide 'temp1_input' i.e. the current drive temperature but does not provide any of the other temperature details. So drives that behave like that, will need to be handled appropriately in the code in regards to max/min and lower/upper critical flagging in the GUI. Even so just the fact it gives the temperature should be ok for most uses.

One other thought: In regards to the meaning of the colours that are used to display temperature:	Color/status of temperature readout	Meaning
White	Within operating temperature
Red	Maximum continuous operating temperature reached
Red Flashing	Critical temperature reached, damage may occur
Black	Minimum continuous operating temperature reached
Black flashing	Minimum critical temperature reached, damage may occur

[Firminator]

Thorough! Hats off. Nothing to add really. This is it.

Maybe one side note to put things into perspective: USB/SATA adapters seem to get really hot, too. Due to the sustained max data transfers during the wipe the IC/chips seem to be able to reach a critical (undocumented) temperature much quicker... and fail. Way earlier than the drive would fail ;) I've had this happen with a cheap adapter in the past. This is just anecdotal and I'm not saying it happens all the time or with all adapters. But something to consider.

[PartialVolume]

I have the same problem with USB adapters, even had one smoke and go pop ! I tend use an ATX PSU now to power the 3.5" drives I plug into the USB port, especially if I'm using an older drive that pulls a lot more startup current.

I've added a little demo routine (which wil get stripped out now it's working) just to test the gui logic in terms of displaying the temperature in it's different forms. The limits I've set are not real world but they will do just to test the code. The real limits will be obtained from the drive and if not available the temperature will remain the default white text on blue background.

https://user-images.githubusercontent.com/22084881/141206940-11edb87d-4111-4cfc-9823-d186db5471f2.mp4

[PartialVolume]

committed https://github.com/martijnvanbrummelen/nwipe/pull/360

[Firminator]

Thanks for the video. Seems to work as intended. I looked at the committed code and was surprised how much work had to be put in. This should be a reminder anytime a feature addition is requested :)

[PartialVolume]

Thanks for the video. Seems to work as intended. I looked at the committed code and was surprised how much work had to be put in. This should be a reminder anytime a feature addition is requesteir of d :)

No problem, regarding the amount of work, yes indeed. For what on the face of it is a small addition it does take a fair amount of code and time. But then nwipe is, I suppose, a fairly complex program, what with it's multiple threads and it's ncurses interface. I just did a search on line to see how much a C programmer in the US gets paid, apparently $40 per hour (I'm assuming that's full time, rather than contract), but based on that hourly rate, adding the temperature feature would have resulted in a invoice of about $900 and that's before I even make the package changes to ShredOS and add the latest nwipe. Luckily I do it for the love of coding :-)

BTW I'll be uploading the latest ShredOS with the nwipe v0.32.003 (temperature edition) this evening.

[PartialVolume]

Now the major part of adding the temperature feature is done, making other additions, like having an nwipe option that either pauses a given thread or even shuts down the computer when the temperature reaches critical should be fairly straightforward (famous last words) :-)

nwipe --temperature_critical=ACTION

Command	ACTION	Info
nwipe --tempcritical=	pause_wipe	just the drives that are critical
nwipe --tempcritical=	pause_all_wipes	All drives critical or not
nwipe --tempcritical=	shutdown computer

[PartialVolume]

@Firminator @Carl-Wilhelm shredos-2020.05.017_x86-64_0.32.003_20211111.img New release for testing, in particular the temperature monitoring should work for all smart drives, but currently will not work with USB drives yet but I'm hoping the developer for the drivetemp module may be able to help with that. If not then I can do some sort of workaround using smartmontools.

[Firminator]

OK thank you so much for the IMG. That'll help testing on different platforms.

I did a quick test earlier compiling NWIPE on my production box (without running an actual wipe) and the log said it detected the temperature on 2 out of 4 drives. So that's quite something already. One of the two failed drives was a SATA SSD with a botched/buggy FW, so drivetemp basically failed with it's native capabilities ("it uses the ATA SCT Command Transport feature to read the current drive temperature") and also it's fallback (reading out SMART attribute 194). Nothing anyone can do here. The other drive is a PCIe NVMe drive. I tried GSmartControl and it also failed to read the temperature. I did then test nvme-cli and it was able to read the temperature. I'll test another NVMe SSD tomorrow on another computer.

[Firminator]

One more addition... drivetemp detects the temperature of the NVMe drive: grep . /sys/class/hwmon/*/name

/sys/class/hwmon/hwmon0/name:acpitz /sys/class/hwmon/hwmon1/name:nvme (this is one of the two drives not detected in current NWIPE) /sys/class/hwmon/hwmon2/name:asus /sys/class/hwmon/hwmon3/name:coretemp /sys/class/hwmon/hwmon4/name:drivetemp (these are the two drives that are detected in current NWIPE) /sys/class/hwmon/hwmon5/name:drivetemp (these are the two drives that are detected in current NWIPE)

So sensors (hwmon drivetemp output using lm-sensors) shows me the NVMe temp:

nvme-pci-0200 Adapter: PCI adapter Composite: +33.9°C

[PartialVolume]

/sys/class/hwmon/hwmon1/name:nvme (this is one of the two drives not detected in current NWIPE)

That's great, thanks for the detailed explanation. Regarding that nvme drive that doesn't show up in nwipe but does appear in hwmon, can you give me a list of all the files/directories under sys/class/hwmon/hwmon1 for that nvme drive. I'm assuming the data files are maybe named differently, so instead of temp1_input etc it's something else.

[PartialVolume]

As a reminder to myself, if we end up using smartmontools data extensively in the new user interface, then I should consider using the --json ouput mode of smartctl and combing that with the json parser library https://github.com/PartialVolume/jsmn to generate a structure in C containing the smartmontools output. Currently I'm simply parsing the text output using string manipulations which is ok for the serial number info as it's only one item (and relies upon smartmontools not drastically changing their current text format) but if I'm going to start pulling more data out of smartmontools a more formal approach would be preferable using the jsmn library.

[PartialVolume]

I did a quick test earlier compiling NWIPE on my production box (without running an actual wipe) and the log said it detected the temperature on 2 out of 4 drives.

I think I'll put the temperature in the drive selection menu as well (if it's not too involved)

[PartialVolume]

.iso now available for v2020.05.017_x86-64_0.32.003

[Firminator]

That's great, thanks for the detailed explanation. Regarding that nvme drive that doesn't show up in nwipe but does appear in hwmon, can you give me a list of all the files/directories under sys/class/hwmon/hwmon1 for that nvme drive. I'm assuming the data files are maybe named differently, so instead of temp1_input etc it's something else.

I'll try to get the data from that other device. I dont have it available right now. However on a good note, on a different computer with a NVMe drive current NWIPE detects the temperature :)

[2021/11/12 11:23:07] info: nwipe 0.32.003 [2021/11/12 11:23:07] notice: Found /dev/nvme0n1, NVME, SM951 NVMe SAMSUNG 512GB, 512 GB, S/N= [2021/11/12 11:23:07] info: Automatically enumerated 1 devices. [2021/11/12 11:23:07] notice: hwmon: Module drivetemp loaded, drive temperatures available

... so I think this is a local issue just on my production box. I'll check "all the files/directories under sys/class/hwmon/hwmon1" on that box later this evening.

I think I'll put the temperature in the drive selection menu as well (if it's not too involved)

That would be super-helpful. :thumbsup:

Thanks for the ISO also. Much appreciated.

[Firminator]

Work note for comparison:

Working NVMe temp on a laptop (accd. to NWIPE log... haven't actually seen the temp in the GUI, but assume it will show):

a) grep . /sys/class/nvme/nvme0/device/hwmon/hwmon[1-9]/{name,temp*}

/sys/class/nvme/nvme0/device/hwmon/hwmon3/name:nvme /sys/class/nvme/nvme0/device/hwmon/hwmon3/temp1_alarm:0 /sys/class/nvme/nvme0/device/hwmon/hwmon3/temp1_input:29850 /sys/class/nvme/nvme0/device/hwmon/hwmon3/temp1_label:Composite

b) corresponding sensors output:

nvme-pci-3d00 Adapter: PCI adapter Composite: +30.9°C

c) all my hwmon sensors on that box using grep . /sys/class/hwmon/*/name

/sys/class/hwmon/hwmon0/name:AC /sys/class/hwmon/hwmon1/name:acpitz /sys/class/hwmon/hwmon2/name:BAT0 /sys/class/hwmon/hwmon3/name:nvme /sys/class/hwmon/hwmon4/name:pch_skylake /sys/class/hwmon/hwmon5/name:coretemp /sys/class/hwmon/hwmon6/name:dell_smm /sys/class/hwmon/hwmon7/name:iwlwifi_1

d) all the files/directories under sys/class/hwmon/hwmon using `ls /sys/class/hwmon/hwmon`where device, power, subsystem are folders

/sys/class/hwmon/hwmon0: device name power subsystem uevent

/sys/class/hwmon/hwmon1: device name power subsystem temp1_crit temp1_input uevent

/sys/class/hwmon/hwmon2: curr1_input device in0_input name power subsystem uevent

/sys/class/hwmon/hwmon3: device name power subsystem temp1_alarm temp1_input temp1_label uevent

/sys/class/hwmon/hwmon4: device name power subsystem temp1_input uevent

/sys/class/hwmon/hwmon5: device temp1_crit_alarm temp2_crit_alarm temp3_crit_alarm temp4_crit_alarm temp5_crit_alarm name temp1_input temp2_input temp3_input temp4_input temp5_input power temp1_label temp2_label temp3_label temp4_label temp5_label subsystem temp1_max temp2_max temp3_max temp4_max temp5_max temp1_crit temp2_crit temp3_crit temp4_crit temp5_crit uevent

/sys/class/hwmon/hwmon6: fan1_input fan1_label fan2_input fan2_label name power pwm1 pwm2 subsystem uevent

/sys/class/hwmon/hwmon7: device name power subsystem temp1_input uevent

[PartialVolume]

[2021/11/12 11:23:07] info: nwipe 0.32.003 [2021/11/12 11:23:07] notice: Found /dev/nvme0n1, NVME, SM951 NVMe SAMSUNG 512GB, 512 GB, S/N=

I see the serial number is missing for that device, I don't know whether you have other models of NVMe devices you can try? just wondered if that's an issue peculiar to that make/model or are all NVMe devices missing the serial number?

[PartialVolume]

[2021/11/12 11:23:07] info: nwipe 0.32.003 [2021/11/12 11:23:07] notice: Found /dev/nvme0n1, NVME, SM951 NVMe SAMSUNG 512GB, 512 GB, S/N=

I see the serial number is missing for that device, I don't know whether you have other models of NVMe devices you can try? just wondered if that's an issue peculiar to that make/model or are all NVMe devices missing the serial number?

I just thought, you probably removed that on purpose. :-)

[Firminator]

Yup, sorry for not XXX ing out. I had to remove a bunch of serial numbers etc in the past that I wished the NWIPE debug smartctl output had the -q parameter with no serial build-in :) But I'm refraining myself for asking for such a feature. So yes there is no problem with the serial number for NVMe.

[PartialVolume]

Not a problem, I can add that to nwipe. I'll probably add "XXXXXXX" for a retrieved serial number and "??????????" for a blank serial number that nwipe was unable to retrieve. I can then still see if we have a problem retrieving the S/N, while keeping serial numbers private.

[Firminator]

That's a good thought.

[Firminator]

Non-working NVMe temp on a different device (NVMe drive in a classic PCIe x4 slot on an ATX mainboard)

a) grep . /sys/class/nvme/nvme0/device/hwmon/hwmon[1-9]/{name,temp*} fails! However after messing around I found that the folder structure is different. This here works: grep . /sys/class/nvme/nvme0/hwmon[1-9]/{name,temp*}

/sys/class/nvme/nvme0/hwmon1/name:nvme /sys/class/nvme/nvme0/hwmon1/temp1_alarm:0 /sys/class/nvme/nvme0/hwmon1/temp1_input:33850 /sys/class/nvme/nvme0/hwmon1/temp1_label:Composite

b) corresponding sensors output:

nvme-pci-0200 Adapter: PCI adapter Composite: +32.9°C

c) all my hwmon sensors on that box using grep . /sys/class/hwmon/*/name

/sys/class/hwmon/hwmon0/name:acpitz /sys/class/hwmon/hwmon1/name:nvme /sys/class/hwmon/hwmon2/name:asus /sys/class/hwmon/hwmon3/name:coretemp /sys/class/hwmon/hwmon4/name:drivetemp /sys/class/hwmon/hwmon5/name:drivetemp

d) all the files/directories under sys/class/hwmon/hwmon using `ls /sys/class/hwmon/hwmon` where device, power, subsystem are folders

/sys/class/hwmon/hwmon0: device name power subsystem temp1_crit temp1_input temp2_crit temp2_input uevent

/sys/class/hwmon/hwmon1: device name power subsystem temp1_alarm temp1_input temp1_label uevent

/sys/class/hwmon/hwmon2: device name power subsystem uevent

/sys/class/hwmon/hwmon3: device temp1_crit_alarm temp2_crit_alarm temp3_crit_alarm temp4_crit_alarm temp5_crit_alarm name temp1_input temp2_input temp3_input temp4_input temp5_input power temp1_label temp2_label temp3_label temp4_label temp5_label subsystem temp1_max temp2_max temp3_max temp4_max temp5_max temp1_crit temp2_crit temp3_crit temp4_crit temp5_crit uevent

/sys/class/hwmon/hwmon4: device power temp1_crit temp1_input temp1_lowest temp1_min name subsystem temp1_highest temp1_lcrit temp1_max uevent

/sys/class/hwmon/hwmon5: device power temp1_crit temp1_input temp1_lowest temp1_min name subsystem temp1_highest temp1_lcrit temp1_max uevent

[PartialVolume]

Can you tell me what grep . /sys/class/hwmon/hwmon1/device displays ?

[PartialVolume]

And also grep . /sys/class/hwmon/hwmon1/device/block Thanks.

[Firminator]

grep . /sys/class/hwmon/hwmon1/device

grep: /sys/class/hwmon/hwmon1/device: Is a directory

grep . /sys/class/hwmon/hwmon4/device/block

grep: /sys/class/hwmon/hwmon4/device/block: Is a directory

[PartialVolume]

What's in /sys/class/hwmon/hwmon1/device/block , if it's another directory, what's it's name?

If there is a single directory go into that and display the name of the subdirectory, I'm expecting it to be nvme or nvme0, if it's nvme is there a further sub directory called nvme0?

[PartialVolume]

Nwipes expecting sys/class/hwmon/hwmon1/device/block/nvme0 or whatever the nvme device name is that's displayed in nwipe.

I've got a sneaking suspicion on your system, it's sys/class/hwmon/hwmon1/device/block/nvme/nvme0 that extra directory would cause nwipe to fail to match the device to the hwmon. It's a easy fix if that's the case.

[PartialVolume]

Sorry, I mean hwmon1, the nvme device, not hwmon4, ignore any reference to hwmon4 I used earlier. I've edited previous comments to correct that.

[Firminator]

I don't have a block device @ /sys/class/hwmon/hwmon1/device/block which is a weird result for a SSD drive.

All I get after tabbing out the hwmon1 folder is this:

device/ name power/ subsystem/ temp1_alarm temp1_input temp1_label uevent

[PartialVolume]

If you cd /sys/class/hwmon/hwmon1/device then ls what's displayed?

[Firminator]

ls -l /sys/class/hwmon/hwmon1/device/

-r--r--r--  1 root root 4096 Nov 11 10:27 address
-r--r--r--  1 root root 4096 Nov 11 10:27 cntlid
-r--r--r--  1 root root 4096 Nov 11 10:27 dev
lrwxrwxrwx  1 root root    0 Nov  9 00:31 device -> ../../../0000:02:00.0
-r--r--r--  1 root root 4096 Nov  9 00:31 firmware_rev
drwxr-xr-x  3 root root    0 Nov  9 00:31 hwmon1
-r--r--r--  1 root root 4096 Nov 11 10:27 kato
-r--r--r--  1 root root 4096 Nov  9 00:31 model
drwxr-xr-x  3 root root    0 Nov  9 00:31 ng0n1
-r--r--r--  1 root root 4096 Nov 11 10:27 numa_node
drwxr-xr-x 11 root root    0 Nov  9 00:31 nvme0n1
drwxr-xr-x  2 root root    0 Nov 13 08:32 power
-r--r--r--  1 root root 4096 Nov 11 10:27 queue_count
--w-------  1 root root 4096 Nov 11 10:27 rescan_controller
--w-------  1 root root 4096 Nov 11 10:27 reset_controller
-r--r--r--  1 root root 4096 Nov  9 00:31 serial
-r--r--r--  1 root root 4096 Nov 11 10:27 sqsize
-r--r--r--  1 root root 4096 Nov 11 10:27 state
-r--r--r--  1 root root 4096 Nov 11 10:27 subsysnqn
lrwxrwxrwx  1 root root    0 Nov  9 00:31 subsystem -> ../../../../../../class/nvme
-r--r--r--  1 root root 4096 Nov 11 10:27 transport
-rw-r--r--  1 root root 4096 Nov  9 00:31 uevent

[PartialVolume]

From the listing that you provided, I can see that for that nvme drive the block directory is missing which is present for other drives like SATA. On a SATA drive there is only one directory under block and it's named with the drive name i.e. sda, sdb etc. and thats how I determine which hwmon belongs to whichever drive.

The typical SATA directory structure doesn't seem to apply to nvme. However I should still be able to identify the drive. Am i correct in thinking that the nvme drive name that appears in the GUI is nvme0n1?

[Firminator]

Yes that's correct:

Btw I grepped for 'block' earlier (using ls -l /sys/class/hwmon/hwmon1/device/* | grep -i block) and found in the nvme0n1 directory the only reference to a block device. The output was:

lrwxrwxrwx 1 root root 0 Nov 9 00:31 subsystem -> ../../../../../../../class/block

The full structure of /sys/class/hwmon/hwmon1/device/nvme0n1 is:

-r--r--r-- 1 root root 4096 Nov 13 10:14 alignment_offset lrwxrwxrwx 1 root root 0 Nov 13 08:32 bdi -> ../../../../../../virtual/bdi/259:0 -r--r--r-- 1 root root 4096 Nov 13 10:14 capability -r--r--r-- 1 root root 4096 Nov 9 00:31 dev lrwxrwxrwx 1 root root 0 Nov 9 20:00 device -> ../../nvme0 -r--r--r-- 1 root root 4096 Nov 13 10:14 discard_alignment -r--r--r-- 1 root root 4096 Nov 13 10:14 events -r--r--r-- 1 root root 4096 Nov 13 10:14 events_async -rw-r--r-- 1 root root 4096 Nov 13 10:14 events_poll_msecs -r--r--r-- 1 root root 4096 Nov 11 10:31 ext_range -r--r--r-- 1 root root 4096 Nov 13 10:14 hidden drwxr-xr-x 2 root root 0 Nov 9 00:31 holders -r--r--r-- 1 root root 4096 Nov 13 10:14 inflight drwxr-xr-x 2 root root 0 Nov 11 11:12 integrity drwxr-xr-x 2 root root 0 Nov 11 11:12 lightnvm drwxr-xr-x 6 root root 0 Nov 11 11:12 mq -r--r--r-- 1 root root 4096 Nov 9 00:31 nsid drwxr-xr-x 5 root root 0 Nov 9 00:31 nvme0n1p1 drwxr-xr-x 2 root root 0 Nov 11 11:12 power drwxr-xr-x 2 root root 0 Nov 9 00:31 queue -r--r--r-- 1 root root 4096 Nov 13 10:14 range -r--r--r-- 1 root root 4096 Nov 9 00:31 removable -r--r--r-- 1 root root 4096 Nov 9 00:31 ro -r--r--r-- 1 root root 4096 Nov 9 00:31 size drwxr-xr-x 2 root root 0 Nov 9 00:31 slaves -r--r--r-- 1 root root 4096 Nov 13 10:14 stat lrwxrwxrwx 1 root root 0 Nov 9 00:31 subsystem -> ../../../../../../../class/block drwxr-xr-x 2 root root 0 Nov 11 11:12 trace -rw-r--r-- 1 root root 4096 Nov 9 00:31 uevent -r--r--r-- 1 root root 4096 Nov 9 00:31 wwid

[PartialVolume]

Thanks, I think I have enough information to make the changes to the code. Also thanks for that snapshot, I was expecting the /dev/ that prefixes nvme0n1 to have been removed with nvme0n1 to be right justified in it's column so the columns remain aligned. I need to look at the bit of code that takes care of that and fix it.

[Firminator]

Off-topic: or move the temp between [wipe] and dev/sda in regards to https://github.com/martijnvanbrummelen/nwipe/pull/361

[PartialVolume]

Code already committed, see https://github.com/martijnvanbrummelen/nwipe/pull/364 and the snapshots attached to that pull request. Hope that looks ok?

The nvme temperature issue is next on the list. I won't make further progress with that until Monday/Tuesday. Followed closely by the -q option.

[Firminator]

Thanks so much for taking time to implement all these changes.

[PartialVolume]

Awesome. Here's a screenshot of the changes - freshly complied: Thanks so much for taking time to implement all these changes.

Looking good ! Will look even better once that nvme column alignment is fixed and it's temperature is showing. I guess that Intel SSD (/dev/sdc) is the one that doesn't report temperature data in any third party program?

[PartialVolume]

One other thing, if you Control-C out of the above screen (with those same drives) can you show me what the summary table looks like.

Reason I ask is that I've got a feeling I remove the /Dev/ in the summary table using an existing function in logging.c If the device alignment looks ok in the summary table I can call the same function for device names (including the path) that exceed 8 characters.