Description of problem: clurmtabd is shipped with rgmanager package, and his supposed mission is to keep in sync the remote nfs mount table (rmtab) in sync between cluster nodes. According to his man page, an instance of clurmtabd should be started for each export, but is not called by any rgmanager component (try running 'grep clurmtabd $(rpm -ql rgmanager)') ... We have set up an NFS cluster (without GFS) and works fine, the only issue we have noticed is that, after relocating an NFS service, we are unable to see what clients are using the exports managed by this service (showmount -a). Is there a way to keep in sync /var/lib/nfs/rmtab in RHCS 5? Version-Release number of selected component (if applicable): rgmanager-2.0.46-1.el5 How reproducible: Always Steps to Reproduce: 1. Create a NFS service 2. Mount this share from a remote client 3. run showmount -a 4. relocate the NFS service 5. run showmount -a on the node that now owns the NFS share Actual results: 'showmount -a' output is empty after relocating the service. Expected results: 'showmount -a' should show the same info after relocating the service. Additional info:
Client mount mapping and the process for generating them changed in the 2.6 kernel, obsoleting clurmtabd. When clients retry after a failure on a Linux 2.6 server, the mount entries are repopulated based on the ACL, rather than going down to rpc.mountd and asking if there's a client:path:refcount entry for that host in /var/lib/nfs/rmtab. So, whether the client had previously mounted or not doesn't matter any more. The server assumes that if a client thought it had mounted the file system, and indeed the client is in the ACL, that it ought to trust the client's state and act as though the client had mounted the file system previously. Because of this, clurmtabd is actually not needed. I'm not entirely sure why it wasn't removed from the build.
Additionally, clurmtabd apparently doesn't correctly handle the rather different rmtab format from Linux 2.6, so even turning it on won't do anything useful without rewriting it first. Clurmtabd was removed upstream some time ago.
We can remove clurmtabd and clurmtabd.8 from the distribution as a matter of cleanliness, but apart from that, I don't see any other 'resolution' to this.
OK. This is the right resolution. The official RHCS documentation is very limited, so removing deprecated components will reduce our reverse engineering efforts in order to search for the full description/options of RHCS components and service options :-\