↧
Same issue.
↧
Just to confirm, this is the
↧
↧
I'm seeing the same issue
I'm seeing the same issue with the released version of the SANlink2 driver (F_MacDrv_V1.2.5_109_Above.zip)
It looks to me like some sort of race condition, where the filesystem is attempted to be mounted before the FibreChannel system is fully online and available to the OS, and then after failing it OS doesn't try and mount the volume again.
↧
Add a delay?
You could try adding a delay like had to be done at various points in the past: https://discussions.apple.com/thread/4434393?tstart=0
The following is untested but is likely to work. Another alternative is to contact AppleCare Enterprise for assistance.
A quick way to do this could be to write out this script to /usr/local/bin/wait4sixty
#!/usr/bin/ruby
sleep 60
exec(*ARGV)
Make sure the script is executable with:
chmod +x /usr/local/bin/wait4sixty
Then copy /System/Library/LaunchDaemons/com.apple.xsan.plist to /Library/LaunchDaemons/com.apple.xsan.plist and change the Program and ProgramArguments parameters like this:
<key>Program</key>
<string>/usr/local/bin/wait4sixty</string>
<key>ProgramArguments</key>
<array>
<string>wait4sixty</string>
<string>/System/Library/Filesystems/acfs.fs/Contents/bin/xsand</string>
</array>
Finally, unload the system xsand.plist and load the one with the delay:
launchctl unload -w /System/Library/LaunchDaemons/com.apple.xsan.plist
launchctl load -w /Library/LaunchDaemons/com.apple.xsan.plist
↧
Thanks a ton, your solution
↧
↧
I've been working with Apple
↧
fibreconfig -l
Seems less than ideal (and more painful than a driver-based remedy or JAMF deviceman work...) but you could use fibreconfig (various queries and greps) to guage link status and visibility, prior to having it query the xsan .plist files / LDAP for mount config (should it mount or not) and then issue the mount command?
Something in-addition-to as opposed to in-the-middle-of feels best when manipulating system/Xsan files, that will no doubt be wiped during any kind of upgrade and/or SIP.
As said, driver-based (or most other things) would be best of course :-)
We have 10.10.x clients with Sonnet chassis, we'll take this as a warning when considering their upgrade.
↧
What I've gathered so far....
Looks like something changed on the OS level in 10.11 (up to 10.11.2 so far) where the mount retries that used to happen until the LUNs were finished scanning, no longer happens. So if the LUNs aren't ready by the time the mount attempt happens, it fails (which was typical at that point in the process), but crucially, it now does not retry as it used to. This may be considered a "feature" or "fix" by Apple since it's likely intended to stop system hangs and increase stability and boot speed. Hopefully if that's the case, or even if it's just a bug, they'll find a way to put the retries back in 10.11.3 or .4, perhaps just for systems that have Xsan enabled.
The beta Promise driver essentially just speeds up the LUN scanning process to try to get more LUNs scanned in time for the mount attempt, but any volumes with LUNs that haven't been scanned in time will still fail to automount. Looks like systems with around 12 or 13 LUNs can be scanned quick enough now, but more than that may not work, and depending on other speed impacting factors, YMMV. If you have priority volumes with a small enough set of LUNs that need automounting, you may want to zone only those LUNs, and perhaps minimize the amount of zoned fibre paths, and see if that helps as a workaround.
@Gerard: If you have a borderline amount of LUNs, small variations in the timing may be the reason behind the inconsistent mounting. And the full filename of the beta driver I received is: F_MacDrv_V1.2.4b2_109_1010.pkg
↧
Rowie,
↧
↧
Mount script workaround
↧
Yes please share!
↧
Here is the script. Once
Here is the script. Once downloaded, change the extension from .txt to .tgz
Run this command:
sudo tar xvzpf (path to .tgz) -C /
You should see something like this next:
x ./
x ./._Library
x ./Library/: Can't set user=0/group=0 for Library
x ./usr/: Can't set user=0/group=0 for usrCan't update time for usr
x ./usr/local/
x ./usr/local/libexec/
x ./usr/local/libexec/xsandelay.py
x ./Library/LaunchDaemons/
x ./Library/LaunchDaemons/com.apple.support.ht205706.xsandelay.plist
tar: copyfile unpack (./Library) failed: Operation not permitted
Note:
When extracting the files with tar, if you see errors specifically about /Library or /usr, you can ignore them.
The first file is the script
The second is the launchd job that kicks off at startup.
Now, the script needs to be activated. To do so, run:
sudo launchctl load -w /Library/LaunchDaemons/com.apple.support.ht205706.xsandelay.plist
Restart, login and wait a few seconds for the Xsan volume to appear.
Rather than simply waiting for a specific amount of time, the script delays Xsan start until the number of targets and LUNs stops changing.
Depending on your network infrastructure, the mount might take a little bit to load, but it does mount and does reappear after a reboot/shutdown.
Hope this helps.
attachment:
↧
Works well...
↧
↧
Did someone tried the 10.11.3
↧
10.11.3 seems to still have the issue.
↧
Compatibility okay
I'm using the Apple dual-channel 4 Gb fibre channel card in a 2009 XServe running OS El Capitan 10.11.2. The server connects directly to a Promise 4 Gb subsystem. The card, which has firmware 1.3.23.0 is working fine. Based on Apple's website, this is the oldest firmware for the card.
It appears that from OS 10.7 the Mac OS has supported FC multipathing. The Promise E610f (Mac version) apparently does not support ALUA however. I've set LUN Affinity on the Promise to use controller 1 for the single logical disk. The second cable is connected to controller 2, which is not receiving or sending data (although it appears some frames are being sent from the server). Controller number 2 should be just for failover.
I could use some more bandwith. Would it be better to move the second cable to controller 1 and not worry about failover? How much benefit would there be? I could buy a 4 port card as well.
Thanks for your advice, Blackfire, and other experts.
↧
Gerard wrote:
Gerard wrote:
Rather than simply waiting for a specific amount of time, the script delays Xsan start until the number of targets and LUNs stops changing.
My Python is a little rusty, but, that is not what it is doing.
Gerard wrote:Depending on your network infrastructure, the mount might take a little bit to load, but it does mount and does reappear after a reboot/shutdown.
The loop is one second, so it will enforce the DELAY_SECONDS. If Xsan tries to run before then (which it will, as that LaunchDaemon plist is still there) all it does is stop it and loop until DELAY_SECONDS has lapsed.
↧
↧
Sanity :-)
I realise that Xsanity can attract some less seasoned colleagues looking for help, so a word of warning about deploying any code (in general) you do not understand and so on.
It's 11pm my time, so I might be missing something, but that HT is also not published.
We'll schedule some time to give this a whirl (same code as provided, and/or our own code that does similar) and if reasonable to do, upload the source for a flat pkg, so those looking to Casper/Munki can do so. Unsure when.
↧
^ I broke the quote tags... :
↧
@BlackF1re
@BlackF1re
We have some of them in SonnetTech chassis, working fine :-)
lafoto wrote:
I could use some more bandwith. Would it be better to move the second cable to controller 1 and not worry about failover? How much benefit would there be? I could buy a 4 port card as well.
Thanks for your advice, Blackfire, and other experts.
Promise did go out of their way to fork the firmware and disable boot didn't they... But ways around that :-O Does the disable/enable LUN Affinity trick not work? (I vaguely remember that.)
If the reasonable budget is there to get a 4-port card that would be best, performance and link resiliency.
↧
Same issue.
Running XSAN v10.11.2
Using a Sanlink 2 (8Gb model)
The XSAN mount doesn't appear after a restart/shutdown unless I;
Delete and reinstall the profile file that I receive from the MDCs.
Mount the XSAN via terminal (sudo xsanctl mount "name of volume")
Just got the v1.2.4b from Promise. Deleted the old driver from /Library/Extensions, per Promise Support, installed the beta then restarted.
My XSAN volume appeared then again after two restarts to verify things work.
Restarted again, but no mount comes up. So, it's a hit/miss for me right now.