On Sun, Dec 13, 2015 at 7:07 PM, Joe Brockmeier <jzb@xxxxxxxxxx> wrote: > On 12/13/2015 07:11 PM, Chris Murphy wrote: >> OK at this moment I'm thinking hdparm and smartmontools just need to >> go on the ISO, along with iotop. > > What's the usage scenario you're picturing here? This feels to me like a > "pet" usage scenario where you're caring a whole lot about a single > server install. Any server with any number of drives. Best practices is to have smartd monitor drive heath and report failures by email or text, rather than via a service disruption or irate human. While smartd could be running in a container, if the container doesn't get state updates when drives are swapped or added, then that requires a workaround: periodically restarting that container. So what's the advantage of running this utility in a container? It's also best practices to disable the write cache on all drives used in any kind of RAID. That's not a persistent setting, so it has to happen every boot. Instead of a boot script or service that does this, a container needs to startup shortly after each boot and do this. What's the benefit of that workflow change? I don't understand that. Another use of hdparm is ATA secure erase before dismissal of drives. If the container not being fully aware of state changes is a bug, then that's fine. In that case a super user highly privilegd container running persistently with sshd running can then be used to do all these things. But I still don't know what the advantage is, having to remote into that container for some tasks, and into the host itself for other tasks. Don't you think there should be some considerable advantage, commensurate with the workflow change caused by relocating simple tools commonly available on servers, to running only in containers instead? I do. -- Chris Murphy _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/cloud@xxxxxxxxxxxxxxxxxxxxxxx
