ZID64 capability of NSS and its usage in different ecosystems, especially with AFP protocol

ZID64 capability of NSS and its usage in different ecosystems, especially with AFP protocol

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

Labels (1)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Comments

Very informative. Thanks for writing this to cover all deployment cases. 

So, what you'd really like to happen is for us all to ditch AFP and go the CIFS route in the medium to long term?! I'm still concerned about how we retrieve legacy data with resource forks in the future.... There could be legal implications in some quarters. Hey ho!

Tom

Hi Tom

This article doesn't intend in suggesting a move from AFP to CIFS, it only cautions the users  about the possible file corruption with AFP when the ZID > 4.2 billion and ways to avoid that corruption. Please note limiting a volume to ZID32 doesn't stop the file IOs untill ZID Ids reach the upper limit of 4.2 billion, if any ZID32 set volume reaches 4.2 billion mark, we can always rezid that volume to release unused ZIDs and resume the file IOs on that volume. 

However, you are right in proposing the roadmap to move from AFP to CIFS  for longer term benefits.The Apple is focusing more on improving SMB stack on it MAC clients and less focused on it's own AFP protocol. In last 3 years the Apple has made SMB as its default protocol to connect to network shares on it's MAC clients and also intends in improvising SMB performance in MAC clients. AFP is still supported by both OES and Apple but the roadmap is set for SMB to be more prominent on MAC clients.

But the query related to resource forks is also very much valid, and so it was also addressed sometime back on OES servers. The novell-cifs is capable of supporting "Alternate data streams" (ADS)which is an equivalent to resource forks.And to migrate resource forks created with AFP to CIFS, there is an "migafp2cifs" cli utility available on OES servers.

So with combination of "Alternate data streams"  (check novcifs man page) and "migafp2cifs" cli , the migration of resource forks to ADS of SMB/CIFS is already tested and  very well supported to help in the migration from AFP to CIFS in OES  deployments.

Thanks,
Manu

Top Contributors
Version history
Revision #:
3 of 3
Last update:
‎2019-07-29 07:55
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.