@coleberhorst Hello again.
There has been speak of a UI switch to show one or the other or a mouse over type thing. Internally the by-id names are used.[quote=“coleberhorst, post:1, topic:3240”]
The reasoning being that all the automated emails only identify the hdd devices by /dev/ path. Or another option would be to change the warning emails for drive smart status.
[/quote]
Yes I much prefer the later, if it’s possible as then at least it will be more dependable, given the sda type names can change from one boot to another and the by-id names contain bus model and serial so if we could possibly move the smart report names over that would be good. And if not then at least an accompanying map of the canonical but non boot stable sda name type to the boot to boot safe by-id names current at the time of the report.
I think it’s a great idea personally as the sda type names are essentially useless to identify a device where as the by-id type names essentially do it all for you in the name alone.
Then you would be surprised. Over the various stints I’ve so far done on the S.M.A.R.T stuff I’ve gotten quite a collection of very poorly drives, ranging from a single bad sector to several thousand with a mix of relocated and un-relocatable. I even have one which has an intermittent dma timeout problem stashed aside ready for when I get around to addressing:
Unless anyone beats me to it of course. May end up not coming in but I’m hoping it will. I feel a little bad connecting them up each time actually as really they should be left in peace and never powered up again; or simply harvested for the magnets of course 
. I’ve also picked up an ex sky box drive that has something like 6 or 8 years of running time and another time I fixed an issue that only occurred in the first 10 hours of a drives life (Seagate model). Once the power on hours reached double digits the problem when away. But luckily I noticed prior to that. So yes poorly and very new drives have definitely played a part in testing. We also have a method built in of ‘faking’ a clients drive: ie the script added to address:
Will generate the smart output from a clients drive and we can then work on that same output on our development systems. It’s been quite a challenge to account for all that we currently do.
Yes me too. I particularly favour the idea of at least accompanying the S.M.A.R.T report with a sda to by-id type name mapping as then even if the Rockstor system is reboot in the mean time, with the consequent possibility of the sda type names changing, you would still have the corresponding by-id type name with which to pin down the exact make model and serial number.
Would you care to make a new GitHub issue suggesting your idea as a feature. Much better to keep a single idea per feature and you can always link back to this forum thread for additional context if you fancied. Not sure exactly how this would be done on the auto smart reports exactly but hopefully we can request it run a script which in turn could attach the by-id type name as well or something; I know nut can do that but not sure of smartctl. I think by default it simply auto emails root which once our email notifications is setup is forwarded. Anyway ‘devils in the detail’ and once the issue is opened hopefully we can amass some ideas of how best it could be done there.
Thanks for your contributions on this one and if you think there are a couple of distinct ideas here then do please make 2 issues as the more focused they are the more likely they are to get attention. It may take quite a while to get around to them but better they exist than not. At least for focused discussion of the specifics of how they might be done.
Thanks.
