Xsan volume UUID

bombich's picture

I use volume name and UUID attributes to positively identify volumes on OS X. For the average HFS+ volume, I can count on the UUID being unique and consistent across the lifetime of that volume. Some of my customers have reported that ACFS volumes, however, get new UUIDs each time the Xsan volume is mounted, e.g.:

diskutil info /Volumes/XSAN | grep "Volume UUID"
Volume UUID: BA3B4176-FE67-3212-AF40-E4C1E710B28C

[Use Xsan tools to unmount and remount the volume, and/or restart the MDC and/or restart the clients -- frankly I don't know which of these actions produces the result]

diskutil info /Volumes/XSAN | grep "Volume UUID"
Volume UUID: 33413E33-7F77-4FC4-BA30-E4B4ABE0FE16

Is this expected behavior, or a configuration problem for these particular Xsan users? I can cope with not being able to rely on the UUID, but I don't want to discard that info without verifying that Xsan volume UUIDs are actually expected to change.

Thanks,
Mike

lucasnap's picture

Good question, I will check it out when I have the change

jsiegers's picture

Yes we have the exact same thing happeningen here:

editset06:Volumes root# xsanctl mount Productie_A
editset06:Volumes root# diskutil info /Volumes/Productie_A/ |grep "Volume UUID"
Volume UUID: 92C3721B-0A66-4FC8-986C-F1A0008C3DB5
editset06:Volumes root# xsanctl unmount Productie_A
editset06:Volumes root# diskutil info /Volumes/Productie_A/ |grep "Volume UUID"
editset06:Volumes root# xsanctl mount Productie_A
editset06:Volumes root# diskutil info /Volumes/Productie_A/ |grep "Volume UUID"
Volume UUID: 35350312-E643-47D3-9A51-A4A422A049C4
editset06:Volumes root#

Perhaps you can determine the volume on name obviously and also MDC?

brianwells's picture

An Xsan volume will get a different UUID each time it is mounted. I suppose a feature request could be made to Apple to ask if it could be more consistent.

At one point we had problems with Archiware P5 where it would try to backup the entire volume every time the volume had been re-mounted. Archiware seems to have changed how they were tracking the volume identity because now it works fine.

lucasnap's picture

Hmm, or.. It can stay the same

metadata02:~ admin$ diskutil info /Volumes/Working |grep "Volume UUID"
Volume UUID: 8A5236D0-B9FE-43AA-B1C7-57AA6000F129
metadata02:~ admin$ sudo xsanctl unmount Working
Password:
metadata02:~ admin$ sudo xsanctl mount Working
metadata02:~ admin$ diskutil info /Volumes/Working |grep "Volume UUID"
Volume UUID: 8A5236D0-B9FE-43AA-B1C7-57AA6000F129
metadata02:~ admin$ sudo xsanctl unmount Working
metadata02:~ admin$ diskutil info /Volumes/Working |grep "Volume UUID"
metadata02:~ admin$ sudo xsanctl mount Working
metadata02:~ admin$ diskutil info /Volumes/Working |grep "Volume UUID"
Volume UUID: 8A5236D0-B9FE-43AA-B1C7-57AA6000F129

lucasnap's picture

Hmm, or.. It can stay the same

metadata02:~ admin$ diskutil info /Volumes/Working |grep "Volume UUID"
Volume UUID: 8A5236D0-B9FE-43AA-B1C7-57AA6000F129
metadata02:~ admin$ sudo xsanctl unmount Working
Password:
metadata02:~ admin$ sudo xsanctl mount Working
metadata02:~ admin$ diskutil info /Volumes/Working |grep "Volume UUID"
Volume UUID: 8A5236D0-B9FE-43AA-B1C7-57AA6000F129
metadata02:~ admin$ sudo xsanctl unmount Working
metadata02:~ admin$ diskutil info /Volumes/Working |grep "Volume UUID"
metadata02:~ admin$ sudo xsanctl mount Working
metadata02:~ admin$ diskutil info /Volumes/Working |grep "Volume UUID"
Volume UUID: 8A5236D0-B9FE-43AA-B1C7-57AA6000F129

Johnny_0_o's picture

Il might be a multipath thing...
Might also depend on the zoning configuration in the switch.
There are a few variables and I am not pretending to understand how it works in the backend.

What I would assume is that the UUID is generated based on a combination of LUN target presented and the FC path/port to access it. Since we are talking FC switches, then this combination would tend to change so the UUID would be different.

Don't take my word for it, this is just my assumption/guess.