Hi All,
I was hoping for some advise regarding how I could improve the glusterfs
package for users (and myself). At least those using openrc, but I
suspect similar may be applicable to systemd, but I have no idea how
systemd handles network mounts so perhaps someone could chip in here on
that front too.
Specifically the mounting of glusterfs file systems currently has a few
problems (glusterd if server=localhost, network, dns(?) and fuse
availability). For now the focus is on the fuse aspect since that's the
biggest annoyance by far.
Mounting happens via the netmount service.
In order for glusterfs to mount successfully the fuse module needs to be
available when mount.glusterfs is invoked. This can be achieved in one
of two ways:
1. Compile the module statically into the kernel.
2. Arrange for fuse service to be started prior to netmount (using say
/etc/conf.d/netmount rc_need="fuse")
I make note that there is specific code in /etc/init.d/netmount in
depend() to handle nfsclient (if there are any nfs and nfs4 mounts it
automatically (unless if the filesystems are also labaled noauto) to
want nfsclient.
Two questions:
1. Would a PR against https://github.com/openrc/openrc/ to add special
case code for glusterfs into netmount have a reasonable chance of being
accepted? I don't like this, it just pushes towards an ever-growing
list of special cases, but it's possibly preferable to having users to
figure out they need to edit /etc/conf.d/netmount to add rc_need="fuse" ?
2. Would it not be an improvement to consider having a more generic
mechanism for other packages to add dependency requirements for
netmount, for example:
/etc/netmound.depend.d/glusterfs(.sh?) could contain a function called
depend_glusterfs() { } which gets invoked if a glusterfs filesystem will
want to be mounted, which I would suggest would have something like:
depend_glusterfs()
{
use glusterd
need net fuse
}
Then if the answer to 2 is yes (which I feel it would be), then a few
implementation details (Will attempt a PR):
What would be the best location for having these files dropped?
Generally I'd say let's stay out of /etc/ for this since these are
system-controlled dependencies, however, some users may have things
rigged and may want to be able to edit or even outright ignore these
dependencies ... ?
/lib/netmount.dependencies.d/ being over-shadowed by
/etc/netmount.dependencies.d?
So any file for which an equivalent in /etc/netmount.dependencies.d/
exist is ignored in /lib/ (similar to udev/rules.d)?
Source all files in those locations, or try them based on filesystem
types to be mounted only (first /etc then /lib variants)?
Kind regards,
Jaco
