[ClusterLabs] Filesystem support for Lustre filesystem client mounts

[Ron Kerry]

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". 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 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.


-- 

Ron Kerry         rkerry at sgi.com
Global Product Support - SGI Federal