In a previous life, I designed and built many SANs based on Xsan (I believe I started with Xsan 1.3). I then migrated to looking after SANs based on SNFS, either from 3rd party vendors, or Quantum.

I believe that the age of Fibre Channel is long over (although SNFS also works on Infiniband if I recall correctly). The advantages of block-level access have been eclipsed by the much higher bandwidth with Ethernet, at a fraction of the cost.

However, I want to share some of my documentation with the world. This is done under an Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) license.

The information has been collected from Apple support articles (current and obsolete ones), ADIC’s and Quantum’s StorNext documentation, and personal experience.

Every Xsan 2.0 and above client has been included. Maybe one day I will add Xsan 1.x releases for historical purposes

	Xsan 20.0	Xsan 5.0.1	Xsan 5	Xsan 4.1	Xsan 4	Xsan 3.1	Xsan 3	Xsan 2.3	Xsan 2.2 to 2.2.2	Xsan 2 to 2.1.1
	11.0.1	10.13, 10.14, 10.15	10.12	10.11	10.10	10.9	10.8	10.7	10.6	10.5
SNFS 7.0.x	✓	✓	✓	❌	❌	❌	❌	❌	❌	❌
SNFS 6.4.0	✓	✓	✓	❌	❌	❌	❌	❌	❌	❌
SNFS 6.3.x	❌	✓	✓	❌	❌	❌	❌	❌	❌	❌
SNFS 6.2.x	❌	✓	✓	❌	❌	❌	?	?	?
SNFS 6.1.x	❌	✓	✓	❌	❌	?	?	?	?	❌
SNFS 6.0.5, 6.0.5.1, 6.0.6	❌	✓	✓	❌	❌	?	?	?	?	❌
SNFS 6.0, 6.01, 6.0.1.1	❌	✓	✓	✓	✓	?	?	?	?	❌
SNFS 5.4.x	❌	✓	✓	✓	✓	?	?	?	?	❌
SNFS 5.3.2.x	❌	✓	✓	✓	✓	✓	✓	✓	✓	❌
SNFS 5.3.1	❌	❌	❌	✓	✓	✓	✓	✓	✓	❌
SNFS 5.3.0	❌	❌	❌	✓	✓	✓	✓	✓	✓	❌
SNFS 5.2.2	❌	❌	❌	✓	✓	✓	✓	✓	✓	❌
SNFS 5.2.1	❌	❌	❌	❌	✓	✓	✓	✓	✓	❌
SNFS 5.2.0	❌	❌	❌	❌	✓	✓	✓	✓	✓	❌
SNFS 5.1.x	❌	❌	❌	❌	❌	❌	✓	❌	❌	❌
SNFS 5.0.x	❌	❌	❌	❌	❌	❌	✓	❌	❌	❌
SNFS 4.7.x	❌	❌	❌	❌	❌	✓	✓	✓	✓	❌
SNFS 4.6	❌	❌	❌	❌	❌	✓	✓	✓	✓	❌
SNFS 4.3	❌	❌	❌	❌	❌	✓	✓	✓	✓	❌
SNFS 4.2.1	❌	❌	❌	❌	❌	✓	✓	✓	✓	❌
SNFS 4.2.0	❌	❌	❌	❌	❌	❌	❌	❌	✓	❌
SNFS 4.1.1 to 4.1.3	❌	❌	❌	❌	❌	❌	❌	✓	✓	✓
SNFS 4.0 to 4.1	❌	❌	❌	❌	❌	❌	❌	❌	✓	✓
SNFS 3.5.x	❌	❌	❌	❌	❌	❌	❌	❌	✓	✓
SNFS 3.1.2 to 3.1.5	❌	❌	❌	❌	❌	❌	❌	❌	❌	✓

There are some caveats with some of the supported configurations. Some releases were originally marked by Apple as incompatible and then reverted. In the same way, some configurations that were originally marked as working were then updated as not compatible.

Double-check official documentation before any deployment.

I hope you find this table useful. There are some additional Xsan curiosities I will post in the future.

In the past it used to be a very straightforward process. You would rename the volume configuration file and run cvfsck.

With newer versions if you try to do that you will get an error message.

To make the name change you can use the cvupdatefs command.

If you have more than one volume running, the below instructions will allow you to rename one volume while the rest are still running, minimising downtime.

Stopping the file system

Stop the file system

# cvadmin -e 'stop oldname_volume1'

Check that it hasn't failed over.

# cvadmin -e 'select'

If it has failed over to another server just run the first command again until the volume you want to rename isn't running.

Check the filesystem

# cvfsck -j oldname_volume1
# cvfsck -nvvvvv oldname_volume1

If errors are shown at the above you need to fix them. Ideally you want to dump inode information before any big repair but that is for another article.

You can fix the errors with:

# cvfsck -vvvvv

Run the above command until there are no errors shown.

Changing the volume name

You can now change the volume name.

# cvupdatefs -R newname_volume2 oldname_volume1

Update the name of the volume in fmslist.

SNFS
# vim /usr/cvfs/config/fsmlist

Xsan
# vim /Library/Preferences/Xsan/fsmlist

In Xsan you need to push the changes to the second metadata server.

# xsanctl pushConfigUpdate

In Xsan you might need to check that the name isn’t referenced in any other configuration file (/Library/Preferences/Xsan), but you can run grep and see where you might need to make changes.

Also in Xsan, if needed, copy the configuration file to the second metadata server. Be aware that Xsan Admin does very often fail to make a good copy of the configuration to the second server. Run a file checksum on both ends and copy the volume configuration file manually if it doesn’t match.

This issue with Xsan Admin will in the best case not allow a volume to fail over, and in the worst case, cause data loss.

In SNFS/Linux you should check for any references of the old name in /usr/cvfs/config/

Also in SNFS/Linux, make sure that the changed files are also updated on the second metadata server.

Remounting the filesystem

In Xsan you don’t need to issue a new profile for the clients to mount the new volume. Just mount it once from the CLI and it will automount on restart:

# xsanctl mount newname_volume2

On Linux clients update entries in /etc/vstab or /etc/fstab to automount the volume on boot.

On Windows clients you will need to use the SNFS configuration tool to mount the newly named volume.

For HA environments Quantum has published an article with the above steps for their systems.