As noted in my previous post on this project, the drives can be triggered from a local shell or by knocking on port 5002. However, neither is easily done from the XMBC interface. The most ideal solution would be activating on demand: when mountd receives a request for a volume that is not mounted nor present, it fires up the PSU to start all drives. Eventually, the requested volume shows up, it gets mounted and all is well.
I decided to settle -for now- for an intermediate solution. When mountd receives a request for a volume with id "
activate", it starts the drives. Since we know in advance there actually is no volume with this name, we don't have to worry about waiting for the device, etc. This would be necessary for true on-demand activation.
With this set-up, I can add a location to XBMC with path
/path/to/rfs/mount/.mounts/activate with name "ChAssNAS activate". If the XMBC user tries to access this location, (s)he gets an error message but knows the drives are being started. After a few seconds, other locations become available, as the volumes are mounted on the ChAssNAS side.
While testing these modifications to mountd (060-activate.patch) I ran into some odd behaviour. Both remotefs and mountd are started at boot time, through the init mechanism of OpenWRT. Whenever remotefs requests a non-existing path on the autofs mount created by mountd, the latter leaps into action and does whatever a mountd does. However, it didn't: mountd did not receive any autofs packages, until either was restarted from shell. After spending almost an entire day trying to find out what's wrong, I called MacGyver. He suggested starting remotefs right after mountd, through an SSH session. The current version of
/etc/init.d/mountd now contains the following line:
/usr/bin/dbclient -i /path/to/private.key localhost
"PATH=/bin:/sbin:/usr/bin:/usr/sbin /etc/init.d/rfsd start"
For shame. But it works now.