[ClusterLabs] Filesystem support for Lustre filesystem client mounts

[Dejan Muhamedagic]

On Mon, May 18, 2015 at 10:38:59AM -0400, Ron Kerry wrote:
> 
> 
> On 5/18/15 10:24 AM, users-request at clusterlabs.org wrote:
> > I suppose that you mean in code like this:
> >
> > 275     # Get the current real device name, if possible.
> > 276     # (specified devname could be -L or -U...)
> > 277     case "$FSTYPE" in
> > 278     nfs4|nfs|smbfs|cifs|glusterfs|ceph|tmpfs|overlayfs|none)
> > 279         : ;;
> >
> > We can add "lustre" to various lists of this kind.
> >
> >>>>>Is this something
> >>>>>> >>>that has been added in the community code, or is this something that
> >>>>>> >>>has yet to be contributed?  Does anyone have another way to handle
> >>>>>> >>>Lustre filesystem client mounts?
> >>>> >There were no changes pertaining to lustre and I can vaguely
> >>>> >recall people using it. I guess that if you do a ML search  (not
> >>>> >this one, but Linux HA or pacemaker) you should find some traces.
> >>>
> >>>There is support for Lustre server (MDS, OSS) mounts because in that
> >>>case the device is a block device.
> >I'm not sure I follow. Sorry, no lustre expert here.
> >
> >>>The trouble stems from the fact
> >>>that the fileysstem type "lustre" is overloaded for both server side
> >>>and client side mount purposes.
> >ocf:heartbeat:Filesystem is essentially mount/umount, so, if we
> >agree on the terminology, it is always client-side.
> >
> 
> Perhaps this will clear up what I mean by overloading the "lustre"
> filesystem type for both Lustre server and Lustre client mounts.
> 
> A Lustre server (MDS or OSS) would have the following sorts of
> /etc/fstab entries:
> 
> # Lustre
> /dev/xscsi/pci-0000:04:08.0-sas-0x1221000001000000-lun0 /lustre/mdt0
> lustre defaults 0 0
> /dev/xscsi/pci-0000:04:08.0-sas-0x1221000002000000-lun0 /lustre/ost0
> lustre defaults 0 0
> /dev/xscsi/pci-0000:04:08.0-sas-0x1221000003000000-lun0 /lustre/ost1
> lustre defaults 0 0
> /dev/xscsi/pci-0000:04:08.0-sas-0x1221000004000000-lun0 /lustre/ost2
> lustre defaults 0 0
> 
> Note that these are block devices and work today with the Filesystem
> resource agent.
> 
> A Lustre "client" system would have the following different sort of
> entry in /etc/fstab:
> 
> # lustre filesystem
> 128.162.245.79 at tcp0:/lustrefs1  /lustrefs1  lustre  _netdev  0 0
> 
> Note that the entry is definitely NOT referencing a block device,
> but instead something that is a network type device similar to what
> NFS would use.
> 
> In BOTH cases the fstype field is "lustre".

I see. So, the filesystem driver is a two-in-one affair.

> This complicates adding
> support for a lustre "client" mount and makes it not so simple as
> just adding it to the list you suggest. I suppose we could "invent"
> a new fstype of "lustre-client" (making sure to map it back to just
> plain "lustre" in the actual mount command) and handle it that way.

I guess that we could also look at the "device" (block vs tcp).
I'm a bit swamped now, but you could open an issue at github and
we can take it from there.

> I can probably hack the Filesystem agent script to get something
> that would work, but I was hoping there was already some sort of
> community solution for this issue.

As I said, I can recall people using lustre, but it must've then
been just the server kind.

Thanks,

Dejan

> 
> -- 
> 
> Ron Kerry         rkerry at sgi.com
> Global Product Support - SGI Federal
> 
> 
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org