Jump to content
SNS Users' Forums
  • Announcements

    • Eric Newbauer

      Follow SNS on Twitter!

      Get notifications via Twitter! Looking for instant updates? We're now also announcing new versions and beta programs via Twitter. Follow Studio Network Solutions on Twitter. Thanks!

Recommended Posts

I am not confused at all about it. I have a new xserve running 10.6, when I boot normally, GlobalSAN System Preferences doesn't work(fails with an error), when I hold 32 and boot, it works fine, which is what ive been having to do to use my RAID over iSCSI... so I was wondering if this new beta fixed that yet or not before I installed it.

It sounds like your hardware is new enough that it boots 64-bit mode by default. There is no 64-bit kernel compatible release of globalSAN yet.

All I wanted to correct was the mention of a "32-bit only" mode in Snow Leopard. Both kernels can run both 32-bit and 64-bit software. The snag comes in if the software includes a kernel extension, as the kernel extensions must match the bit-width of the kernel they're extending. All of our software has components that function at that level, which is why there is a requirement for globalSAN.

I haven't seen the error given when attempting to load the Preference Pane when booted from a 64-bit kernel, but the cause would be that the Preference Pane expects the kernel extension to have been loaded, but that is the part that needs the 32-bit kernel.

I should also mention that the 3.3 release of globalSAN doesn't officially support Snow Leopard at all. The new 4.0 beta provides support for Snow Leopard booted on a 32-bit kernel, but 64-bit kernel support is still in the works.

Share this post


Link to post
Share on other sites

It sounds like your hardware is new enough that it boots 64-bit mode by default. There is no 64-bit kernel compatible release of globalSAN yet.

All I wanted to correct was the mention of a "32-bit only" mode in Snow Leopard. Both kernels can run both 32-bit and 64-bit software. The snag comes in if the software includes a kernel extension, as the kernel extensions must match the bit-width of the kernel they're extending. All of our software has components that function at that level, which is why there is a requirement for globalSAN.

I haven't seen the error given when attempting to load the Preference Pane when booted from a 64-bit kernel, but the cause would be that the Preference Pane expects the kernel extension to have been loaded, but that is the part that needs the 32-bit kernel.

I should also mention that the 3.3 release of globalSAN doesn't officially support Snow Leopard at all. The new 4.0 beta provides support for Snow Leopard booted on a 32-bit kernel, but 64-bit kernel support is still in the works.

Ok, thanks for the information. I was under the impression that there was 3 modes for snow leopard. A mixed 32/64 mode which was the normal boot for some systems in which you had a 32 bit kernel but could spawn 64 bit processes fine... a 32 bit only mode which was all 32 bit and could only run 32 bit processes, and a 64 bit only mode where you can only spawn 64 bit processes because you have a 64 bit kernel. I guess I was mistaken on that front and its just 32 bit and 64 bit where the 32/64 mode I thought was there is just the 32 bit normal mode and my hard ware is new enough to not use that by default. I will wait on installing the 4.0 beta right now just because what I have works fine as long as its in 32 bit mode and really really hope that you guys will release that 64 bit beta soon.

Thanks for the support.

Share this post


Link to post
Share on other sites

Ok, thanks for the information. I was under the impression that there was 3 modes for snow leopard. A mixed 32/64 mode which was the normal boot for some systems in which you had a 32 bit kernel but could spawn 64 bit processes fine... a 32 bit only mode which was all 32 bit and could only run 32 bit processes, and a 64 bit only mode where you can only spawn 64 bit processes because you have a 64 bit kernel. I guess I was mistaken on that front and its just 32 bit and 64 bit where the 32/64 mode I thought was there is just the 32 bit normal mode and my hard ware is new enough to not use that by default. I will wait on installing the 4.0 beta right now just because what I have works fine as long as its in 32 bit mode and really really hope that you guys will release that 64 bit beta soon.

Thanks for the support.

Well, there are three modes:

1) On machines that are flat out incapable of running 64 bit, the kernel boots into 32 bits, and will only launch apps in 32 bit mode. If an app isn't "fat" and doesn't have a 32-bit version, it won't run. Only Core Solo and Core Duo machines fall into this category.

2) New machines with 64-bit EFI, which have Mac OS X Server 10.6 installed, will boot into the 64-bit kernel by default. Only machines with 64-bit EFI are capable of this mode; the original MacPro, or most Core 2 Duo machines, don't have 64-bit EFI, and as a result can't boot into the 64-bit kernel. Machines that have only 10.6 (client) installed can be booted into this mode by holding down the 6 and 4 keys simultaneously, as long as they have 64-bit EFI. A machine that's running a 64-bit kernel can run 64 and 32 bit applications, but it can only load 64 bit kernel extensions. That's why the SNS iSCSI doesn't work in this mode; the ATTO initiator does.

3) All machines that aren't covered by (1) and (2) will boot into the 64-bit mode with 32-bit kernel. This mode will execute 64 bit and 32 bit applications, and will load 32 bit kernel extensions. Running 64-bit applications under the 32-bit kernel comes at a small price if the applications need to allocate more than 2GB of space (not 4GB as is often said). The OS will then basically perform memory banking. So if you are running 64-bit apps that commonly want to use more than 2GB private memory, you are better off running the 64-bit kernel. But otherwise, the apps are still getting all the benefits of 64-bit, such as better memory mapped files, as well as the whole 64-bit instruction set.

Relatively few machines can actually boot into the "full" 64-bit mode, because only the very recent units shipped with 64-bit EFI. The most surprising one is probably the original MacPro, which is a true Xeon 64-bit machine but has only 32-bit EFI.

If you want to boot your machine in the "other" mode than the default, assuming the "other" mode is supported, you can hold down either 6 and 4 or 3 and 2, respectively. To make this change permanent, you can:

To set your machine to boot into 64 bit mode enter this command and reboot:

sudo systemsetup -setkernelbootarchitecture x86_64

To set your machine to boot into 32 bit mode enter this command and reboot:

sudo systemsetup -setkernelbootarchitecture i386

It may make sense to switch your Nehalem MacPro running 10.6 Server to 32-bit mode if you need to use the SNS initiator, or some other kernel extensions (such as all eSATA cards that I have come across so far).

Share this post


Link to post
Share on other sites

I have tried the Beta version on my new XServe and it is not loading correctly. It says it is missing the driver and to do the re-install and that is not fixing the issue. I was hoping to get this server connected to the SAN soon but it looks like that might have to wait. Also when I click on the iniator in the preferences it closes it and then reopens it, I saw on a previous forum that this could be permissions related so I went and did the permissions fix but to no availo, any ideas would be great!

Share this post


Link to post
Share on other sites

I have tried the Beta version on my new XServe and it is not loading correctly. It says it is missing the driver and to do the re-install and that is not fixing the issue. I was hoping to get this server connected to the SAN soon but it looks like that might have to wait. Also when I click on the initiator in the preferences it closes it and then reopens it, I saw on a previous forum that this could be permissions related so I went and did the permissions fix but to no availo, any ideas would be great!

Hello,

Thanks for posting :)

Which version of OSX server are you working with?

Did you also try trashing the globalSAN iSCSIConfig.plist.? This knowledge base article describe the procedure.

-ryan

Share this post


Link to post
Share on other sites

Hello,

the beta Version on my Snow Leopard crashes permanent after short successfull connection, and the performance is so poor.

It is simply not to use, i went back to Version 3.x.

Unfortunately I have to take care that the system will not go to sleep to avoid kernel panic.

Share this post


Link to post
Share on other sites

I have Snow leopard (10.6.2) and I tried both versions 3.3.0.43 and 4.0.0.197. I had to transfert (rsync) several hundred of Gb of data (Time Machine backups) and I found my laptop frozen several time. If it wasn't all the OS, It was the finder stack.

Disabling the iSCSI target on my NAS ( Synology 210J) saved the OS one time. Others times I had to do an hard reboot.

Cheers,

Share this post


Link to post
Share on other sites

Hello,

the beta Version on my Snow Leopard crashes permanent after short successfull connection, and the performance is so poor.

It is simply not to use, i went back to Version 3.x.

Unfortunately I have to take care that the system will not go to sleep to avoid kernel panic.

What target are you using?

We would like to troubleshoot this behavior. If possible, please send a system profile from the workstation where the issue is reproducible to iscsi@studionetworksolutions.com

-ryan

Share this post


Link to post
Share on other sites

I have Snow leopard (10.6.2) and I tried both versions 3.3.0.43 and 4.0.0.197. I had to transfert (rsync) several hundred of Gb of data (Time Machine backups) and I found my laptop frozen several time. If it wasn't all the OS, It was the finder stack.

Disabling the iSCSI target on my NAS ( Synology 210J) saved the OS one time. Others times I had to do an hard reboot.

Cheers,

Hello,

Thanks for the detailed feedback.

We would like to investigate this behavior. If possible, please send a system profile from the workstation where the issue is reproducible to iscsi@studionetworksolutions.com

regards,

ryan

Share this post


Link to post
Share on other sites

What target are you using?

We would like to troubleshoot this behavior. If possible, please send a system profile from the workstation where the issue is reproducible to iscsi@studionetworksolutions.com

-ryan

Hello,

I'm using an iSCSI Target on FreeNAS 0.7 AMD64 hosted on a ZFS mirror. When I get a dump I will send you, first I have to reinstall the Beta 4.

The configuration looks like this:

iqn.2009-11.jp.ne.peach.istgt:iDiskMac1 rw LUN0=/mnt/Pool1ZFS/DSiSMac1/iDiskMac280

Share this post


Link to post
Share on other sites

I just tried 4.0.0.197 an hour ago and have found similar issues. The target gets connected for a short period of time, then gets disconnected but the volume remains mounted. Any attempt to unmount/eject it gives a "grr, i'm busy" error. Spotlight attempts to index the drive, and ends up freezing and taking Finder (or the entire mac; i.e beachball of doom) down with it. I've switched back to 3.3.0.43 and everything's swell again except for the ~5 minute delay between bootup and connecting to the targets.

On the bright side of things, I really like the GUI of v4 more than 3.3's. Much cleaner and easier to navigate things. Far less confusing!

On a second side note, would it be possible to have the pref panel open without reloading it into 32-bit? Would make configuration smoother.

P.S. I'm using a QNAP TS-439 Pro w/ 3x 640GB RAID5 on a 2008 iMac running 10.6.2.

Share this post


Link to post
Share on other sites

I just tried 4.0.0.197 an hour ago and have found similar issues. The target gets connected for a short period of time, then gets disconnected but the volume remains mounted. Any attempt to unmount/eject it gives a "grr, i'm busy" error. Spotlight attempts to index the drive, and ends up freezing and taking Finder (or the entire mac; i.e beachball of doom) down with it. I've switched back to 3.3.0.43 and everything's swell again except for the ~5 minute delay between bootup and connecting to the targets.

On the bright side of things, I really like the GUI of v4 more than 3.3's. Much cleaner and easier to navigate things. Far less confusing!

On a second side note, would it be possible to have the pref panel open without reloading it into 32-bit? Would make configuration smoother.

P.S. I'm using a QNAP TS-439 Pro w/ 3x 640GB RAID5 on a 2008 iMac running 10.6.2.

Glad you like the new UI :)

Unfortunately we're still not able to reproduce this behavior on any of the targets we test. Would you be willing to do a remote session so we can reproduce the issue in your environment?

-ryan

Share this post


Link to post
Share on other sites

Glad you like the new UI :)

Unfortunately we're still not able to reproduce this behavior on any of the targets we test. Would you be willing to do a remote session so we can reproduce the issue in your environment?

-ryan

ryan,

As much as I'd love to, I'd rather not poke my setup anymore (for now). School's crazy, moved a few days ago, Snow Leopard itself has been very unstable for me lately, and after spending several hours getting things back to normal I'd rather leave it alone in peace. I'd be happy to test a new release in the future, especially as I plan to upgrade my array to larger drives.

Might be helpful if you have globalSAN create its own log file? It sometimes does, and sometimes doesn't, update the main console log and hard to tell what's happening. Otherwise, do you need anything specific? I might feel bored one night and might try it again. Would be nice to know what to look for.

Cheers,

-robodude666

Share this post


Link to post
Share on other sites

I think I will uninstall it from my system, too.

The system is not really stable any more. The drive is busy and shutdown does not function correctly.

I had to do a hard turn off very often the last time, this cannot be good.

Share this post


Link to post
Share on other sites

Anyone experiencing sleep/hibernate issues after trying globalSAN Beta v4 please run the following debug build and reproduce the issue:

http://www.snsftp.com/guest/globalSAN-4.0.0.198_sleepdebug.dmg

After reproducing the issue, Please run the following diagnostic information retrieval script so we can gather the debug info:

http://www.snsftp.com/guest/SNS-INFO_v.3.zip

Execute SNS-INFO command:

1. Save the archive file containing the script to your desktop, and

double-click to extract it.

2. Double-click the unarchived file named "SNS-INFO.command".

3. The script will begin. Once the script completes, it will create an

archive of the retrieved logs named "logpackage-<date & time>.tar.gz" to the

desktop.

4. Email the resulting text file to iscsi@studionetworksolutions.com

Thanks in advance for everyone's assistance. We look forward to hearing from you.

-ryan

Share this post


Link to post
Share on other sites

Hi

I am still having the problems described in this post using the final V4 of SNS. Is there still a solution? In the current state the SNS is useless for me......

Tanks.

RA

Anyone experiencing sleep/hibernate issues after trying globalSAN Beta v4 please run the following debug build and reproduce the issue:

http://www.snsftp.com/guest/globalSAN-4.0.0.198_sleepdebug.dmg

After reproducing the issue, Please run the following diagnostic information retrieval script so we can gather the debug info:

http://www.snsftp.com/guest/SNS-INFO_v.3.zip

Execute SNS-INFO command:

1. Save the archive file containing the script to your desktop, and

double-click to extract it.

2. Double-click the unarchived file named "SNS-INFO.command".

3. The script will begin. Once the script completes, it will create an

archive of the retrieved logs named "logpackage-<date & time>.tar.gz" to the

desktop.

4. Email the resulting text file to iscsi@studionetworksolutions.com

Thanks in advance for everyone's assistance. We look forward to hearing from you.

-ryan

Share this post


Link to post
Share on other sites

I've used both the 3.3 and 4.0 initiators on 10.5 with no problems. I recently (finally) updated to 10.6 and the 4.0 version was causing a lot of problems. It would work fine for a while and then all traffic to it would stop and the processes trying to use it would stall and become non-responsive. After several occurrences I reverted back to 3.3 and things seem to be working fine again.

My target is istgt on FreeBSD 8.0 AMD64.

P.S. I also can't seem to shutdown cleanly with the initiator running, 3 or 4.

Share this post


Link to post
Share on other sites

Hi,

I'm running an iMac on Mac OS X 10.6.3 with globalSAN iSCSI Initiator 4.0 build 204, connecting to an iSCSI target on a Synology CS407 running DSM 2.3-1157. I'm using simple CHAP, digest for header only and default sizes for segments. This config seems stable enough (copied back and forth several tens of GBs), up until the point where the connection with the target is broken unexpectedly (e.g. when stopping the iSCSI service on the Synology, while the initiator is still connected). At this point, any process on the iMac trying to access the iSCSI target hangs badly (doesn't even respond to kill -9), until the system is restarted. As shutdown tries to unmount file systems cleanly before rebooting, it hangs as well. If unlucky, even a sync command from Terminal might hang and consequently, reboot, so a forced power off is often the only resolution. Graphical applications like Finder, Disk Utility or the globalSAN iSCSI preference pane can be Force Quit, but won't restart afterwards. They're still shown (between brackets) by ps -A from Terminal.

I know, I'm not supposed to break the target before the initiator has been disconnected. However, I find this happens when the iMac goes into sleep for a longer period of time (e.g. overnight). The Synology shows the target as Ready (no active connection), the globalSAN iSCSI preference pane shows Disconnected, but won't react to Connect. When the volume on the target disk is ejected before the iMac goes to sleep, Finder survives, but Disk Utility hangs when trying to access the target disk. The iSCSI connection does seem to survive a shorter sleep period (one hour or less?), however.

As far as I can tell, this seems to be a bug in the iSCSI initiator. As said, otherwise the config seem stable. Doing a clean shutdown on the iMac, while the initiator is connected to the target works as expected. When the connection is marked Persistent, it gets reconnected automatically after system startup.

Please let me know if you need help to reproduce this situation or if you want me to provide additional info. I'm looking forward to be able to access my iTunes library over iSCSI, which is much faster than NFS and, hopefully, more persistent than CIFS.

Thanks, Erik.

Share this post


Link to post
Share on other sites

I'd also like to echo that some of those problems are also present when using 3.3 under Snow Leopard (10.6.1-10.6.3). It works splendidly, until I send my iMac into a sleep state. If the sleep period is longer than about an hour, any function done after waking up the iMac that requires the iSCSI connection causes that particular application to freeze/crash/become unusable. Generally speaking, it also yields a chain reaction of malfunction.

For example, if I try to use a spotlight search after waking up my iMac, spotlight freezes with the beach ball of doom. Shortly thereafter Finder goes down. Attempting to open the Preferences Pane to check on globalSAN gives an indefinitely bouncing icon.

As another example, after waking up my iMac iTunes works fine.. I can listen to my music just fine, etc. as they are stored on my local disk. Going into the podcast section yields a beach ball of doom and iTunes goes down. Attempting to relaunch iTunes yields a "iTunes file is locked" error which requires a hard reset because the system will not restart otherwise. Attempting to access the iSCSI volume via finder to see if it's still connected shows the root list of folders, as they were already viewed before the iMac was put to sleep state. Attempting to go down into any folder deeper than root yields a beach ball, Finder freezes and a hard reset is required. Generally speaking, the iMac then does 2 or 3 chime restart loops before it's able to boot up.

SNS, I love your iSCSI Initiator product... I really do. It works well.. Sorry, worked well. Now? Not so much. I understand it's a free product, but you can't expect to have people pay thousands for your paid products if they see this level of support here.

I'm a web developer, as well as a person who enjoys his computer. I love music, movies and anime. All of which requires a lot of storage. I use a Mac because I like the performance, and don't have to worry about things. Using an external NAS is the best option I've come across for large volume storage whilst being able to use a fairly affordable iMac.. Unfortunately, you're making it rather impossible to continue with my current configuration. I've been stressed out by this iSCSI issue ever since Snow Leopard came out. All we've seen out of you was a couple posts, a "it doesn't happen to us" reply, two beta releases, and a final 4.0 release that has the same problems as the beta. Please don't make me spend more money on a new FireWire storage device. My networked NAS hardware works just fine, so there's no need to replace it.. but if I must, I must.

-robodude666

Share this post


Link to post
Share on other sites

Hey Everyone, thanks for the detailed reports. We are investigating this behavior. We're not able to reproduce this issue with our EVO target, EMC, IBM, or EqualLogic. Anyone willing to let us do a remote session?

-ryan

Share this post


Link to post
Share on other sites

Hey Everyone, thanks for the detailed reports. We are investigating this behavior. We're not able to reproduce this issue with our EVO target, EMC, IBM, or EqualLogic. Anyone willing to let us do a remote session?

-ryan

I tried several configurations. I am using 10.6.3 and a QNAP TS509-Pro FW 3.2.6. At least I found out, that using any Authentication I get the failures described above. After awaking my Mac my desktop show me the connected drives but accessing them results in a freeze of the finder. The pref pane of the iSCSI Initiator show me, that the drives are not connected. And I cant connect or disconnect them from the pref pane. And the NAS connection log don't show a correct log in log out.

After turning of authentications it works fine. All mode of the iSCSI Volumes, the NAS is offering, are working well (i.e. expandable volume size, fixed volume size)

I think authentication is getting a timeout, when the NAS spin down the drives (power safe) when there has been no disc activities for a while. If I resume after a few seconds, I don't experience any difficulties.

We can do a remote session. But before doing so, I will take the time, the mac must be in hibernate to determine, after which time the error will occur.

-reinhard

Share this post


Link to post
Share on other sites

I tried several configurations. I am using 10.6.3 and a QNAP TS509-Pro FW 3.2.6. At least I found out, that using any Authentication I get the failures described above. After awaking my Mac my desktop show me the connected drives but accessing them results in a freeze of the finder. The pref pane of the iSCSI Initiator show me, that the drives are not connected. And I cant connect or disconnect them from the pref pane. And the NAS connection log don't show a correct log in log out.

After turning of authentications it works fine. All mode of the iSCSI Volumes, the NAS is offering, are working well (i.e. expandable volume size, fixed volume size)

I think authentication is getting a timeout, when the NAS spin down the drives (power safe) when there has been no disc activities for a while. If I resume after a few seconds, I don't experience any difficulties.

<...>

-reinhard

That's brilliant! I disabled CHAP, made a permanent connection to the iSCSI target on my Synology NAS box and then took the target offline on the Synology. Now, instead of hanging, the Mac pops up a message telling me not to do this: "The disk was not ejected properly. If possible, always eject a disk before unplugging it or turning it off." The globalSAN preference pane shows the target as Disconnected, yet Persistent. After re-enabling the target, the driver re-appears on the Mac and the globalSAN preference pane shows status Connected. This is the behaviour I wanted :) ! I suppose that's what you get for being paranoid on your own home LAN... :unsure:

I suppose this takes care of the sleep issue as well. I'll keep the drive connected overnight and check again tomorrow.

EDIT: Indeed, Mac woke up fine this morning. The iSCSI drive was not showing, but it connected automatically within 30 seconds.

@Ryan, I PMed you about setting up a remote session, please let me know if I can help.

Cheers,

Erik.

Share this post


Link to post
Share on other sites

reini, you are brilliant! After doing a hard reboot on my iMac after waking it up not long ago, I went into the QNAP settings and disabled CHAP for both of my iSCSI targets. I also disabled CHAP in the globalSAN preferences pane, and upon restarting the iSCSI volumes mount INSTANTLY too my desktop as the dock rose up. Million thanks!

Going to install globalSAN 4.0 later tonight and see how well my iMac plays tomorrow morning after it's been asleep for a few hours.

Cheers,

-robodude666

Share this post


Link to post
Share on other sites

Hello,

--------------

Mac Mini - Mac OS X Server 10.6.3 (10D578)

Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386

NAS QNAP TS-459 - Version 3.2.6 build 0423T

iSCSI Target with a mapped LUN

target : naspartition

cible alias : nas

username : nas

pass : xxxxxxxxxxxx

iscsi LUN

LUN allocation : Thin Provisioning

LUN name = 001

LUN Location = Mirror Disk: Drive 3 4

partition size 1800 Gb

GlobalSAN - Version 4.0 (Build 204)

--------------

My experience so far ...

Since I discard Spotlight from indexing the drive (in system preferences), everything's seems to work perfectly.

But I continue my testing, with or without auth, ...

HISTORY (BEFORE discarding Spotlight)

-------

There are no users connected (admin only).

The server is freshly started.

No problems to connect to the target.

=> The target has about 100Gb of data already copied on it

I've tried with or without authentication.

I've tried with or without persistent.

The state of the connection become orange after a while.

On the left pane, it is still green.

After a night (without persistent) all was red. Disk was unmounted.

On orange state :

This situation blocks any opened or newly opened window from listing the content.

If there was a copy action between directories, this is friezed.

After a while, it is possible to disconnect (not eject) the iscsi drive (with bad ejection message) and after it has been ejected to reconnect (state to green).

Where can I send my logs?

Many thanks for your work at this point,

Michel

Share this post


Link to post
Share on other sites

Welp, v3 crashed my OS a couple times so I gave v4 a go again but first updated my target to the latest. Same old issues though, it transfered a bunch of data and then stalled. I captured packets while it was stalled, no traffic. Tried to stop the transfer, disconnect session and eject the mount, still no traffic. None of the options were able to complete so another reboot to clear it and now I'm stuck with no reliable connection.

Share this post


Link to post
Share on other sites

×