NSS volumes traditionally supported creation of files/directories upto 0xffffffff ,in common terms upto ~4.2 billion objects on a volume. And if any of the volume reaches this mark, the only option was to rezid that volume by putting the entire pool into maintenance state, meaning a down time for the end users.

OES understood the problem and released patches for OES11SP2, OES11SP3, OES2015, OES2015SP1 to support ZID beyond 4.2 billion mark, which was called as ZID64 feature and so the same feature was also included in OES2018 and above releases.

So now there is no down time and no need to rezid the volume which has hit 4.2 billion mark,we can just use command line tools to enable that particular volume to ZID64, as simple as it!!

But then what does this document do?
Well, the commands and enabling the volume to ZID64 mode is very simple but we really need to understand their usage based on the deployments.


Let’s take deployments:
Deployment 1- Local and Cluster volumes on OES2015SP1 and previous releases:
All Local and Cluster volumes in any of the mentioned servers are by default in ZID32 mode, meaning the files can’t be created beyond 4.2 billion count without any admin interference.

Deployment 2- Local volumes on any of OES2018 and above releases:
All Local volumes in any of the mentioned servers are by default in ZID64 mode, meaning the files can be created beyond 4.2 billion count without any admin interference.

Deployment 3- Cluster having mix of OES2015SP1 or older and OES2018 or above:
Whenever the cluster has OES2015SP1 or older servers in it, then all the shared volumes in that cluster are by default in ZID32 mode, meaning the files can’t be created beyond 4.2 billion count without any admin interference.

Deployment 4- Cluster having mix of OES2018 and/or above OES versions:
Whenever the cluster has only OES2018 and above in it, then all the shared volumes in that cluster are by default ZID64 mode, meaning the files can be created beyond 4.2 billion count without any admin interference.


With above deployments, let us understand with more practical scenarios:
(1) cluster with mix of OES2015* and OES11*:
    -All local volumes in any of these nodes are default ZID32 mode
    -All shared volumes in any of these nodes are by default ZID32 mode

(2) cluster with mix of OES2015* and OES2018*:
    -All local volumes in any of the OES2015* nodes are default ZID32 mode
    -All local volumes in any of the OES2018* nodes are default ZID64 mode
    -All shared volumes in any of these nodes are by default ZID32 mode

(3) cluster with only OES2018 servers:
   -All local volumes in any of these nodes are by default ZID64 mode
   -All shared volumes in any of these nodes are by default ZID64 mode

(4) cluster with only OES2018SP1 servers:
   -All local volumes in any of these nodes are by default ZID64 mode
   -All shared volumes in any of these nodes are by default ZID64 mode

(5) cluster with mix of OES2018 and OES2018SP1 servers:
   -All local volumes in any of these nodes are by default ZID64 mode
   -All shared volumes in any of these nodes are by default ZID64 mode

As we can see from above five scenarios, cluster/shared volumes ZID mode depends on if OES2015SP1 or older servers are part of the cluster. If the cluster only has OES2018 and above servers in it, then all shared volumes are default ZID64 mode.

The above should be very clear on what is ZID mode and the default of ZID mode in different scenarios but it doesn’t end there if any of the deployments has AFP protocol to access NSS volumes.


AFP and ZID64 mode:
AFP protocol by design can’t work with ZID IDs beyond 4.2 billion mark, meaning AFP protocol can only work with ZID32 mode. This limitation is not from OES end, it’s the way Apple has implemented AFP protocol itself.

So it’s no-brainer that we should not allow NSS volume to go beyond 4.2 billion ZID count if we have AFP protocol accessing NSS volume otherwise it would lead to the file corruption when the ZID IDs go beyond 4.2 billion mark. But many of the above scenarios has default ZID64 mode especially i) Local volumes of OES2018 and above servers, ii) shared volumes in the cluster of OES2018 and above servers

So it’s best practice to force the NSS volume to ZID32 mode,which has AFP protocol enabled and regularly accessing the NSS volume with AFP protocol.

To enforce any NSS volume to ZID32 mode on OES2018 and above servers:
Using the new mount options for each volume by manually editing /etc/fstab for local volumes and the cluster load script for shared volumes as below:

For shared volumes:
exit_on_err ncpcon mount /opt=zid32 CVOL=volumeID
exit_on_err ncpcon mount /opt=ns=UNIX,zid32 CVOL=volumeID (If we have namespace already added,just add zid32 as shown in this line)

For local volumes:
VOLNAME /media/nss/VOLNAME nssvol noauto,zid32,rw,name=VOLNAME, 0 0


And to enforce any NSS volume to ZID64 mode on OES2018 and above servers:
1)Using the new mount options for each volume by manually editing /etc/fstab for local volumes and the cluster load script for shared volumes as below:

For shared volumes:
exit_on_err ncpcon mount /opt=zid64 CVOL=volumeID
exit_on_err ncpcon mount /opt=ns=UNIX,zid64 CVOL=volumeID (If we have namespace already added, just add zid64 as shown in this line)

For local volumes:
VOLNAME /media/nss/VOLNAME nssvol noauto,zid64,rw,name=VOLNAME, 0 0

2) /ForceEnableZID64 and /ForceVolumeZID64Mode:

nss /ForceEnableZID64: This is server level switch applicable to shared volumes only.So This option may not be appropriate if the shared volumes are moving across the cluster nodes unless this option is enabled on all cluster nodes and added in nssstart.cfg to persist the value even after the reboot. Please note that this option is also available in OES2015*,OES11SP2 and OES11SP3 servers.

nss /ForceVolumeZID64Mode=<vol_name> :This is volume level switch applicable to both shared and local volume.This option is useful when the ZID32 mode is reached and user started seeing file operation failures due to ZID32 mark,under such scenarios -on the live system without any downtime this switch will change the ZID mode of the volume from ZID32 mode to ZID64 mode allowing user to continue file operations. So this is a runtime option to enable zid64 mode particularly designed to support this scenario.


Finally, how to know ZID mode of any volume on OES2018 and above servers:
The /var/log/messages will clearly have the ZID mode and through which ways the zid mode is set amongst all of the above different ways of enabling/disabling ZID32 or ZID64.

Additionally if administrator wants to check which zid mode the volume is , then VolumeInfo.xml will have the latest mode of the volume.

---------------------------------------------------------------------------------------------
for eg: cat /_admin/Manage_NSS/Volume/NSSVOL22/VolumeInfo.xml | grep -i zid
<nextAllocatableZid>1664</nextAllocatableZid>
<zidMode>zid64</zidMode>
<zid64Enabled>false</zid64Enabled

zidMode:
Indicates that volume can grow beyond 4.2 billion mark if the value is zid64
Indicates that volume can’t grow beyond 4.2 billion mark if the value is zid32

zid64Enabled:
Indicates that volume has already gone beyond 4.2 billion mark if its true
Indicates that volume has not yet gone beyond 4.2 billion mark if its false
---------------------------------------------------------------------------------------------


Please remember that if the volume has gone beyond 4.2 billion mark, we can’t set that volume to zid32 mode through any of the ways, it will always set itself to zid64 mode since it’s gone beyond 4.2 billion mark.

That’s all, hopefully this should help in understanding and implementing the ZID64 in the different needs and deployments you come across. Thank you!!

*Conventions in this write-up:
shared volumes - volumes which are cluster enabled or cluster volumes
4.2 billion mark  - exact value is 2^32