search

thomas-krenn / TKperf

Performance test tool for SSDs, HDDs and RAID devices
https://www.thomas-krenn.com/en/wiki/TKperf
GNU General Public License v3.0
48 stars 23 forks source link

Varying hdparm output leads to crash of frozen check #29

Closed chris-iot closed 5 years ago

chris-iot commented 6 years ago

Some disks do not have the security feature set built in and therefore hdparm -I does output fewer lines. Especially those used to check the frozen state are missing in case the security features are not included.

Security: 
    Master password revision code = 65534
        supported
    not enabled
    not locked
        frozen
    not expired: security count
        supported: enhanced erase
    2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

This leads to a crash of TKperf. Unfortunately i don't have a stacktrace... but if you need one just write me.

A possible workaround would be to continue the test process if the block is missing and assume that the drive is OK (not locked or frozen). If hdparm's return code is != 0 an exception should be raised nevertheless, to notice fatal hdparm errors.

Another possible thing to do is to check the hdparm -I output if the security features are available. If they are hdparm's output can be parsed. If they are not it is assumed that the drive is OK unless hdparm's return code is not equal zero (that indicates a fatal error). If this does not work in a satisfying way the last option is to look for vendor specific tools to replace hdparm to query the drive state, but normally this is nasty and work intensive as such a tool must be integrated for every vondor, so it should be the last option...

Here are to hdparm -I outputs, one with and one without the security features. security-feature-builtin.txt security-feature-missing.txt

This issue is loosely related to #28 as this also contains an approach to check if the security features are available or not.

This issue was also discussed in today's meeting with @gschoenberger so he already knows about it.

gschoenberger commented 5 years ago

This issue is resolved by commit 3cd8d91f23fc09cc60e0987cda90096071bc97fc If the device does not support the enhanced erase feature, blkdiscard is tried to run instead. If blkdiscard is not supported a Warning log entry is generated but the test continues

gschoenberger commented 5 years ago

Here are log entries, for a device not supporting secure erase, but blkdiscard.

20181107 14:58 root INFO # Checking for Enhanced Secure Erase with hdparm 20181107 14:58 root INFO # Running command: hdparm -I /dev/sdf | grep -q "supported: enhanced erase" 20181107 14:58 root WARNING # Enhanced Secure Erase NOT supported by device /dev/sdf 20181107 14:58 root INFO # Trying to discard all blocks with blkdiscard. 20181107 14:58 root INFO # Discarded all blocks with blkdiscard: /dev/sdf: Discarded 256060514304 bytes from the offset 0

20181107 14:58 root INFO # Succesfully used blkdiscard as Secure Erase not supported by device: /dev/sdf 20181107 14:58 root INFO # Starting preconditioning round 0