Linux – Replaced storage controller, now can’t find ESXi ZFS mount point

infinibandlinuxstoragevmware-esxizfs

We have an older file server (running Gentoo of all things) that recently suffered a storage controller failure. The parts were replaced and everything is back online except one item, probably the most important: the ESXi mount point.

The former sysadmin, while brilliant, never kept notes for any changes. There's nothing in FSTAB or CRONTAB or any 'normal' place to create mounts. Running zfs list shows all the ZFS mount names, but has a blank for the mount point. My coworker and I are poring through log files trying to find any indication of historical mounts, but there's nothing. This is connected to the open-source licensed compute server via infiniband, but unsure whether it's shared via NFS, iSCSI, or what. Like I said, no notes to work from.

Best Answer

This is so little information to go on, but I'll try to edit this answer as needed...

Please show the output of:

zpool list zpool status -v zfs list

And possibly http://pastebin.com the zpool history output for me.

Okay, that fileserver is a terrible mess. I'm sorry your organization is in this situation without documentation.

I'm actually concerned about how this was done... It's a perfect example of unpaid technical debt... but the core issue is that your Xen and VMware shares are not NFS. They are comprised of ZFS zvols here. That means that ZFS is presenting a block device to the hypervisors that's formatted using their native filesystems. I don't know if iSCSI is in the mix here, but if you post zpool history, I may be able to determine what was done.

Related Solutions

Linux – /proc/self/mountinfo per-mount-options vs per-super-options

/proc/self/mountinfo is the most authoritative source to check your mounts.

/proc/mounts is a deprecated source to check the status of your mounts.

The reason (in the linked bug report) that it says to avoid using it, is that it doesn't produce extra info that might be important in certain scenarios (whether it is a shared mount, private, unbindable etc, which only applies when using mount namespaces) and as such is technically deprecated in favour or /proc/self/mountinfo.

This distinction is not relevant for older distros. EL5 for example does not completely support separate namespaces, so the case for /proc/self/mountinfo is not useful.

If you're really just interested in mount flags /proc/mounts is fine.

Note that /proc/mounts symlinks to /proc/self/mounts because the 'mount view' that the process sees is on a per-namespace basis and processes may be in different namespaces. For the vast majority of use-cases, this exception really shouldn't apply (you'd know if you were using mount namespaces).

Linux NFS – How to Change UID Between Linux Systems

If I understand you correctly, then you want to map all request from client node to a specific UIG/GID on the server. For this you have to adjust your exports file as following:

/home/rdebXXX/test dev-www(rw,sync,no_subtree_check,anonuid=512,anongid=1003,all_squash)

The all_squash option tells server to map all requests to user nobody and the corresponding UID and GID you already have in the export options.

Best Answer

Related Solutions

Linux – /proc/self/mountinfo per-mount-options vs per-super-options

Linux NFS – How to Change UID Between Linux Systems

Related Topic