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

Yes, you must have a LUN0. This behavior is the same for all releases of globalSAN.

Errrr.... No. I haven't changed anything on my NAS and it works with v4.1.

Share this post


Link to post
Share on other sites

All this wait and it doesn't work!!! I was willing to buy it right away but i thought to test it first. I am glad I did.

I am running 10.7.2 with Synology 3.2

I hope it doesn't take forever again to be fixed.

Share this post


Link to post
Share on other sites

Definitely crashing on my system as well. Clearly shows a lack of attention to detail and testing.

I've quieted the messages by using launchctl to permanently unload the failing daemon. Not sure why it's even set to start on systems that aren's using the target feature.

Yeah - indeed. I will try to find out why the Aladdin HASP is installed in the first place…

Cheers,

budy

Share this post


Link to post
Share on other sites

Sorry that there is an issue. I assure you GlobalSAN v5 does work. There are many users successfully using it. We would like to address this issue right away but we need your help. We need additional information to investigate. We ask that you please collect traces and send log files to the email address in the instructions below. Also, please note in your submission if you are willing to grant us remote access to the troublesome environment. Thank you for your patience. We look forward to resolving the issue ASAP.

Regards,

SNSryan

Here's a suggestion...

How about given that you've decided to start charging for this product, why don't you invest in equipment to replicate the issue in your test labs. Frankly, that you expect everyone else to beta test your now commercial product FOR YOU is disgusting.

If people are good enough to do YOUR testing in THEIR production environments for you, then you need to cough up free licenses for anyone doing so. Just sayin...

Share this post


Link to post
Share on other sites

Here's a suggestion...

How about given that you've decided to start charging for this product, why don't you invest in equipment to replicate the issue in your test labs. Frankly, that you expect everyone else to beta test your now commercial product FOR YOU is disgusting.

If people are good enough to do YOUR testing in THEIR production environments for you, then you need to cough up free licenses for anyone doing so. Just sayin...

Totally agree with you. How many people work in this company? is it a 2 or 3 people company? I am really thinking to give my money to ATTO and leave this forum for ever. It's just frustrating.

Share this post


Link to post
Share on other sites

All this wait and it doesn't work!!! I was willing to buy it right away but i thought to test it first. I am glad I did.

I am running 10.7.2 with Synology 3.2

I hope it doesn't take forever again to be fixed.

what problem are you having?

Share this post


Link to post
Share on other sites

Ok folks, let put some perspective on this. No matter what the size of the company, the idea of testing for all possible setups is an impossibility. We're talking about 20+ manufacturers, each with multiple models and each model having multiple possible firmware levels. Now add in multiple operating systems with many possible patch levels. These guys would have to invest in hundreds of devices to try to completely test the software. No one is doing that no matter what size company they are. Not even ATTO. We wouldn't have the software for another year while we waited for them to test every obscure configuration. I trust them when they say many users are running the software successfully. Now we can help them fix the issues for the rest of us. I, personally, will be sending in my trace and diag data as soon as possible.

Share this post


Link to post
Share on other sites

Totally agree with you. How many people work in this company? is it a 2 or 3 people company? I am really thinking to give my money to ATTO and leave this forum for ever. It's just frustrating.

18 employees right now. We are hiring for 3 positions as well.

What problem are you experiencing?

Share this post


Link to post
Share on other sites

I believe the crashing can be solved by updating the Sentinel HASP Mac OS X Run-time Script Installation which can be found on "http://hasp.com/support/hasp-srm/enduser.aspx" I haven't had a crash event since installing.

I can now see the following errors in the console when trying to connect to the Synology target

19/10/2011 18:08:06.444 _spotlight: audit warning: closefile /var/audit/20111019170546.20111019170806

19/10/2011 18:08:06.446 _spotlight: audit warning: allsoft

19/10/2011 18:08:06.453 _spotlight: audit warning: soft /var/audit

19/10/2011 18:08:25.000 kernel: GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0xffffff800c405c00) will be ignored.

19/10/2011 18:08:25.000 kernel: IBMDiskArrayController5::probe fails

19/10/2011 18:08:25.000 kernel: GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0xffffff800c405c00) will be ignored.

19/10/2011 18:08:25.000 kernel: EMCDiskArrayController5::probe fails

19/10/2011 18:08:25.000 kernel: Couldn't alloc class "NO_EVOInitiator"

19/10/2011 18:08:26.000 kernel: IOSCSIMultipathedLogicalUnit: Failed to Add Path 0xffffff800d650c00

Share this post


Link to post
Share on other sites

I believe the crashing can be solved by updating the Sentinel HASP Mac OS X Run-time Script Installation which can be found on "http://hasp.com/support/hasp-srm/enduser.aspx" I haven't had a crash event since installing.

I can now see the following errors in the console when trying to connect to the Synology target

19/10/2011 18:08:06.444 _spotlight: audit warning: closefile /var/audit/20111019170546.20111019170806

19/10/2011 18:08:06.446 _spotlight: audit warning: allsoft

19/10/2011 18:08:06.453 _spotlight: audit warning: soft /var/audit

19/10/2011 18:08:25.000 kernel: GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0xffffff800c405c00) will be ignored.

19/10/2011 18:08:25.000 kernel: IBMDiskArrayController5::probe fails

19/10/2011 18:08:25.000 kernel: GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0xffffff800c405c00) will be ignored.

19/10/2011 18:08:25.000 kernel: EMCDiskArrayController5::probe fails

19/10/2011 18:08:25.000 kernel: Couldn't alloc class "NO_EVOInitiator"

19/10/2011 18:08:26.000 kernel: IOSCSIMultipathedLogicalUnit: Failed to Add Path 0xffffff800d650c00

It should be also noted, that the HASP daemon is not needed for the GlobalSAN initiator, but it needed/intended for the target part. Therefore anyone can safely disable it by simply typing this into the Terminal.app:

launchctl unload -w /Library/LaunchDaemons/com.aladdin.hasplmd.plist

This will terminate and inactivate the HASP daemon immediately and thus stop the crashes, which by the way, don't harm the initiator from functioning at all. I had GlobalSAN .5 already up and running for days, when I actually stumbled across this, while looking at this thread.

Share this post


Link to post
Share on other sites

Ok folks, let put some perspective on this. No matter what the size of the company, the idea of testing for all possible setups is an impossibility. We're talking about 20+ manufacturers, each with multiple models and each model having multiple possible firmware levels. Now add in multiple operating systems with many possible patch levels. These guys would have to invest in hundreds of devices to try to completely test the software. No one is doing that no matter what size company they are. Not even ATTO. We wouldn't have the software for another year while we waited for them to test every obscure configuration. I trust them when they say many users are running the software successfully. Now we can help them fix the issues for the rest of us. I, personally, will be sending in my trace and diag data as soon as possible.

Well… I definitively would too, if I could - but "unfortunately" GlobalSAN .5 just works with my COMSTAR targets (1 MBP with one target and a Mac mini connecting to three targets).

I guess whatever the root cause for the connections issues between GlobalSAN v.5 and the likes of Synology/ReadyNAS are, I bet that they're the same reasons it didn't work with GlobalSAN 4.1 as well.

Cheers,

budy

Share this post


Link to post
Share on other sites

I just installed the latest version of globalSAN that is intended to work with Lion. No luck. I get the green light that my iSCSI target is connected but it doesn't mount.

I am currently running the diagnostic tool that SNS provided and will send in my logs. Hopefully this will help you create a version that will work for all of us.

I'm using a ReadyNAS Pro Pioneer with Lion 10.7.2.

-Matthew

Share this post


Link to post
Share on other sites

I believe the crashing can be solved by updating the Sentinel HASP Mac OS X Run-time Script Installation which can be found on "http://hasp.com/support/hasp-srm/enduser.aspx" I haven't had a crash event since installing.

I can now see the following errors in the console when trying to connect to the Synology target

19/10/2011 18:08:06.444 _spotlight: audit warning: closefile /var/audit/20111019170546.20111019170806

19/10/2011 18:08:06.446 _spotlight: audit warning: allsoft

19/10/2011 18:08:06.453 _spotlight: audit warning: soft /var/audit

19/10/2011 18:08:25.000 kernel: GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0xffffff800c405c00) will be ignored.

19/10/2011 18:08:25.000 kernel: IBMDiskArrayController5::probe fails

19/10/2011 18:08:25.000 kernel: GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0xffffff800c405c00) will be ignored.

19/10/2011 18:08:25.000 kernel: EMCDiskArrayController5::probe fails

19/10/2011 18:08:25.000 kernel: Couldn't alloc class "NO_EVOInitiator"

19/10/2011 18:08:26.000 kernel: IOSCSIMultipathedLogicalUnit: Failed to Add Path 0xffffff800d650c00

I can see similar kernel messages:

GLO Warning: Failed to set TOS (error 22)

GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0x64efc00) will be ignored.

IBMDiskArrayController5::probe fails

GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0x64efc00) will be ignored.

EMCDiskArrayController5::probe fails

Couldn't alloc class "NO_EVOInitiator"

GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0x64efc00) will be ignored.

IOSCSIMultipathedLogicalUnit: Failed to Add Path 0xf1ea900

GLO Warning: Error 32 while receiving BHS.

GLO Warning: Receiving thread has stopped with error 32.

IOSurface: buffer allocation size is zero

IOSurface: buffer allocation size is zero

IOSurface: buffer allocation size is zero

GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0x7ef2800) will be ignored.

IBMDiskArrayController5::probe fails

GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0x7ef2800) will be ignored.

EMCDiskArrayController5::probe fails

Couldn't alloc class "NO_EVOInitiator"

GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0x7ef2800) will be ignored.

IOSCSIMultipathedLogicalUnit: Failed to Add Path 0x693d700

GLO Warning: Error 32 while receiving BHS.

GLO Warning: Receiving thread has stopped with error 32.

GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0x6539000) will be ignored.

IBMDiskArrayController5::probe fails

GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0x6539000) will be ignored.

EMCDiskArrayController5::probe fails

Couldn't alloc class "NO_EVOInitiator"

GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0x6539000) will be ignored.

IOSCSIMultipathedLogicalUnit: Failed to Add Path 0x686e800

GLO Warning: Error 32 while receiving BHS.

GLO Warning: Receiving thread has stopped with error 32.

No disk devices have been created after connecting:

localhost:~ root# ll /dev/disk*

brw-r----- 1 root operator 14, 0 Oct 19 20:25 /dev/disk0

brw-r----- 1 root operator 14, 1 Oct 19 20:25 /dev/disk0s1

brw-r----- 1 root operator 14, 2 Oct 19 20:25 /dev/disk0s2

brw-r----- 1 root operator 14, 3 Oct 19 20:25 /dev/disk0s3

I'm using a Synology DS 211j for my iSCSI target.

Share this post


Link to post
Share on other sites

Ok folks, let put some perspective on this. No matter what the size of the company, the idea of testing for all possible setups is an impossibility. We're talking about 20+ manufacturers, each with multiple models and each model having multiple possible firmware levels. Now add in multiple operating systems with many possible patch levels. These guys would have to invest in hundreds of devices to try to completely test the software. No one is doing that no matter what size company they are. Not even ATTO. We wouldn't have the software for another year while we waited for them to test every obscure configuration. I trust them when they say many users are running the software successfully. Now we can help them fix the issues for the rest of us. I, personally, will be sending in my trace and diag data as soon as possible.

Exactly and that is why they should have in place an outside Beta team in order to test the equipment they do not have in house.

Share this post


Link to post
Share on other sites

Exactly and that is why they should have in place an outside Beta team in order to test the equipment they do not have in house.

Sure, that's a fair point. I bet they'd get quite a few volunteers to help beta test if they asked. I'd certainly participate in that.

Share this post


Link to post
Share on other sites

We have reached out to both Synology and NetApp. So far, Synology has agreed to send us a unit right away. We are committed to bringing compatibility to as many targets as possible, as soon as possible. We implemented the 14-day trail so that users could try before they buy for this very reason. We would have liked to have tested more targets before the release but there are simply too many out there. I apologize for any inconvenience. We will have a solution very soon.

If you are truly open to helping resolve the issue right away please send logs and packet captures to iscsi@studionetworksolutions.com. A few of you have done so already, thank you! However, the fastest path to resolution would be for us to gain remote access to one of these offending targets as soon as possible. If you are willing, please send an email to iscsi@studionetworksolutions.com

Share this post


Link to post
Share on other sites

connection's state became green, but my Mac(10.7.2) couldn't mount the disk yet.

Log messages of my ReadyNAS Ultra 6 when globalSAN v.5 attempted to connect the ReadyNAS.

> Oct 20 20:48:07 ReadyNAS kernel: TARGET_CORE[iSCSI]: Registered fabric_sess_ptr: ffff88002995b500

> Oct 20 20:48:07 ReadyNAS kernel: iSCSI Login successful on CID: 544 from 172.16.100.20 to 172.16.100.32:3260,1

> Oct 20 20:48:07 ReadyNAS kernel: Incremented iSCSI Connection count to 1 from node: naa.****

> Oct 20 20:48:07 ReadyNAS kernel: Established iSCSI session from node: naa.****

> Oct 20 20:48:07 ReadyNAS kernel: Incremented number of active iSCSI sessions to 2 on iSCSI Target Portal Group: 1

> Oct 20 20:48:07 ReadyNAS kernel: Unknown VPD Code: 0xc8

> Oct 20 20:48:07 ReadyNAS kernel: Unknown VPD Code: 0xc0

> Oct 20 20:48:07 ReadyNAS kernel: Received data_length: 16 too small for EVPD 0xb0

> Oct 20 20:49:09 ReadyNAS kernel: Decremented iSCSI connection count to 0 from node: naa.****

> Oct 20 20:49:09 ReadyNAS kernel: TARGET_CORE[iSCSI]: Deregistered fabric_sess

> Oct 20 20:49:09 ReadyNAS kernel: Released iSCSI session from node: naa.****

> Oct 20 20:49:09 ReadyNAS kernel: Decremented number of active iSCSI Sessions on iSCSI TPG: 1 to 1

Share this post


Link to post
Share on other sites

I am successfully connecting to an OpenFiler ver 2.3 with Lion 10.7.2 and GlobalSan V5

Write speed is great 60-65MB/s

Read speed of the same file is terrible at 250-600KB/s?

I will re-check with SL 10.6.7 and GS V4.1, but I don't remember having such terrible read speeds before?

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

Checked SL 10.6.7 & GS V4.1

Same file & equipment used in previous test, just a different startup disk used.

Write speed is 45-55MB/s

Read speed is 40-50MB/s

Seems read speeds with V5 might be an issue?

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

Ignore this! - After removing all the Login Items the speeds are now fine under Lion, further investigation required to find what application is causing the issue.

Edited by TorranceTM

Share this post


Link to post
Share on other sites

Well. Just for the ###### of it I tried reinstalling globalSAN v5 without the HASP component. AND I renamed my LUN-1 to LUN0... Still no dice.

Seem to get these joyful messages in console when I connect:

24/10/2011 22:37:43.759 authexec: executing /bin/mv
24/10/2011 22:37:43.769 authexec: executing /usr/sbin/chown
24/10/2011 22:37:43.799 authexec: executing /bin/mv
24/10/2011 22:37:43.806 authexec: executing /usr/sbin/chown
24/10/2011 22:37:43.819 authexec: executing /bin/mv
24/10/2011 22:37:43.826 authexec: executing /usr/sbin/chown
24/10/2011 22:37:43.000 kernel: GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0xffffff80103c6000) will be ignored.
24/10/2011 22:37:43.000 kernel: IBMDiskArrayController5::probe fails
24/10/2011 22:37:43.000 kernel: GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0xffffff80103c6000) will be ignored.
24/10/2011 22:37:43.000 kernel: EMCDiskArrayController5::probe fails
24/10/2011 22:37:43.000 kernel: Couldn't alloc class "NO_EVOInitiator"
24/10/2011 22:37:44.000 kernel: IOSCSIMultipathedLogicalUnit: Failed to Add Path 0xffffff800db82400

Share this post


Link to post
Share on other sites

Well. Just for the ###### of it I tried reinstalling globalSAN v5 without the HASP component. AND I renamed my LUN-1 to LUN0... Still no dice.

Seem to get these joyful messages in console when I connect:

24/10/2011 22:37:43.759 authexec: executing /bin/mv
24/10/2011 22:37:43.769 authexec: executing /usr/sbin/chown
24/10/2011 22:37:43.799 authexec: executing /bin/mv
24/10/2011 22:37:43.806 authexec: executing /usr/sbin/chown
24/10/2011 22:37:43.819 authexec: executing /bin/mv
24/10/2011 22:37:43.826 authexec: executing /usr/sbin/chown
24/10/2011 22:37:43.000 kernel: GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0xffffff80103c6000) will be ignored.
24/10/2011 22:37:43.000 kernel: IBMDiskArrayController5::probe fails
24/10/2011 22:37:43.000 kernel: GLO Warning: Tail (34 of 98 bytes) of the Data Segment (PDU 0xffffff80103c6000) will be ignored.
24/10/2011 22:37:43.000 kernel: EMCDiskArrayController5::probe fails
24/10/2011 22:37:43.000 kernel: Couldn't alloc class "NO_EVOInitiator"
24/10/2011 22:37:44.000 kernel: IOSCSIMultipathedLogicalUnit: Failed to Add Path 0xffffff800db82400

Ehh… what do you mean by "I renamed my LUN-1 to LUN0"? You can't actually "rename" a LUN. LUN0 (1,2,3,4,...) refers to the LUN ID of the scsi device that your target assigned it. Since iSCSI is based on SCSI, there's this old Controller-Device/LUN in place, where the Device-ID was known as the SCSI-ID and the LUN-ID was mostly 0 since there were seldom more than one device attached to a SCSI-Controller.

Now with iSCSI this has changed. The SCSI-ID has been, for simplicity's sake, exchanged with the target/portal and LUN-ID is assigned to each volume that is served by that target.

I had a Thecus NAS that just wouldn't assign LUN0 to the first LUN i created on it, since VMWare tends to have issues with it. And for the sake of VMWare-compatibility my NAS always left out LUN0 and started with LUN1. I had to hack into the firmware to get this going.

However, there are initiators that will scan all LUNs, even if LUN0 is missing, since a missing LUN0 indicates that there are no other LUNs on that target, which I not explicitly states in the RFC, afaik.

I wonder if GlobalSAN will scan for the remaining LUNs if LUN0 is missing.

Cheers,

budy

Share this post


Link to post
Share on other sites

Check for updates in system preferences for globalSAN iSCSI initiator is indicating that version 5.0.0.290 is available, but after install it is still 5.0.0.279?

Manual download offers the old version of 5.0.0.279?

Share this post


Link to post
Share on other sites

Ehh… what do you mean by "I renamed my LUN-1 to LUN0"?

Well. Synology has a name for each LUN and it defaults to calling the first for LUN-1. So i presumed that was what we where talking about. It don't actually show the SCSI ID of it anywhere. So I guess it could be anything. But since it used to work just fine, I guess it is indeed 0.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×