Closed Reinitialized closed 1 year ago
You're using a SAS drive, and this tool has weak support for SAS drives -- because I don't own any to test with. Example: the script looks for "Device Model", "Model Family", or "Model Number" to identify the disk model -- your SAS disk returns none of these, just "Product". Another example: the script looks for "Serial Number" for the serial number -- your SAS disk uses lower-case 'n' ("Serial number"), so it misses that, too.
Alright, I'll do a fork and see if I can adapt it to handle SAS disks better. I currently only have the one model, but depending on how these go I may have others soon. I'll also change the title of this issue to reflect the problem, and it would be nice if you added a help-wanted label so we could see about getting others involved with a variety of models.
Interestingly, it seems I've ran into an issue involving the reporting of SMART capabilities, as these HDDs return nothing. Is this normal?
Seems I worked on that without noticing there is this open issue: https://github.com/Spearfoot/disk-burnin-and-testing/pull/22
I'll use this chance to say thank you @Spearfoot for saving me lots of time. I was just about to hack a little script together to burnin and log information on my 15 heterogenous drives, but you already invented that wheel in a nice and clean way. <3
Closed since work is already being done on #22
It appears the issue is relating to weak logic surrounding SAS models. However, more test cases should be provided to confirm if this is indeed a protocol difference, or a difference in how manufacturers report SMART data.
It appears the script is incorrectly parsing smartctl results, as the script reports the following:
but
sudo smartctl --all /dev/sda
clearly shows the expected dataExpected behavior: Correctly parse the results of smartctl so the script can function accordingly.