Dynamic Exports
While adoption of the integrated protocol stack “CES” with users of IBM Spectrum Scale is rising, we did get a lot of complaints for having to restart the NFS Server when client definitions for an export had to change.
Its all packaged in the CLI, but still it creates an impact by invoking the NFS Grace period.

The 5.0 release did bring the long waited for relief – we called it “dynamic exports”. It does inform the server(s) about the changes without having to restart it.

Obviously, in a research HPC cluster this is not such a big topic. The system is set up, a number of exports is defined – and its used. The dynamics is in the workload, the jobs the scheduling, the NFS setup changes rarely.

Scale
Now when there is a need to change NFS exports frequently – new projects are started, an new Openstack instance needs access to an NFS export – what was called “dynamic exports” are really in demand.

Something else comes into focus too – there are a lot of exports – the execution time for a change.
Over the years, we have collected a bit of overhead – so changing a single export may take 2+ minutes.
A long time even considering the command is making cluster-transactions and keeps up to 32 NFS server machines in sync.

How does Spectrum Scale 5.0.2 help ?
We have redone the CLI for NFS. Thrown away the old code. Only kept the syntax. Fixed a few bugs too.
see mmnfs man page

Effect –
25x improvement in run-time for mmnfs export change. What used to take 2+ minutes now can run in 5 seconds.
It helps for both changing – mmnfs export change – and removing exports – mmnfs export remove
As the GUI does invoke the same code, GUI users benefit too.

This is how NFS exports became more dynamic in Spectrum Scale 5.0.2.

Join The Discussion

Your email address will not be published. Required fields are marked *