[mythtv-users] Disk Power Control

[Ian Bonham]

Dear All,

My Video Collection is stored on USB Media Player hard disks, so I can take
a Video disk out to Friends houses & play stuff on their TV's.
This works very well, with fstab mounting disks by UUID. In this way I have
a /media/video directory, and under that I mount the disks as Lib1, Lib2 and
so on. Myth just indexes everything under /media/video. As my Mythbackend is
a headless box next to the front door (So I can grab a disk from the rack on
the way out) I've put Asterisk on it, and programmed some extensions to
umount disks cleanly if I dial their number.

Now I am thinking 'green' though and have been looking at ways of reducing
my power usage. I have seen a €20 multigang socket which supports power
filtering, and strike protection for phone/antenna. However the feature I
really like is the mains sockets can be USB controlled. 1 socket stays live
24/7, and the other 7 can be switched on/off via USB.

I have been looking at scripts that can use /proc/diskstats to detect if a
drive has been idle, and then send a spin-down signal to the disk. I was
thinking of modifying this system so rather than just spinning down a disk,
I can unmount it, and then turn off power to the socket on the multigang it
is connected to.

However, where as a spin-down is a 'soft power down' and the disk spins back
up when it gets a new request across the bus, in this case I would be
physically turning off the power brick for the disk.

Obviously what I need to do is detect either a request to the device, or an
attempted read of the related mount point, which would then trigger power
back to the relevant multigang socket.

Has anyone ever worked on a project such as this? If so, would you be
willing to let me know if you achieved it and how?

I appriciate I could just whip the disks out of the caddies and put them on
an IDE bus to program the disk it's self with hdparm, but using USB
Externals, I like the idea of being able to turn off the transformer brick
as well. Less energy, less fire risk and so on.

If anyone can offer any suggestions, I'd appriciate your advice,

Yours,

Bon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-users/attachments/20090202/cecb7839/attachment.htm>