Comment 8 for bug 1660240

As I review this code around the tune_dev a bit further, various questions come to mind. For one, the UUID of the /dev/<disk> generally isn't set as that's set on the partition not on the device itself, so I don't expect the disk itself to have a UUID. Commit https://github.com/openstack/charms.ceph/commit/69b691edafae7e10be878c41c34ab2fbfecaedfc should actually prevent this exception from being raised as the UUID will be None and therefore will bail on the autotune, but it makes the autotune ineffective as I believe that in general the UUIDs for the disk will be None. However, this code change was not synced into the ceph-osd charm recently and therefore the exception is still encountered in the latest charm (17.02 release, ceph-osd-241).

The documentation around hdparm seems to imply using the /dev/disk/by-id/<disk-id> for settings in the hdparm.conf file, but I'm not sure how to determine this value other than checking the various links in /dev/disk/by-id and resolving the os.path.realpath to the device in question. So instead of searching for the UUID, the code should probably be searching for the disk's id instead. Also, there are some classes of disks that should be skipped because the hdparm utility doesn't actually support them; namely these include certain virtual disks which are not attached via SCSI, SAS, or SATA. This limitation should really only affect testing scenarios though.

Finally, the tuning in question sets the read_ahead value for the disk to 256. However, all systems I've seen in practice set this value to 256. I'm curious if this might be the default value but admit to not knowing yet exactly how the default read_ahead is chosen.