Jump to content
SNS Users' Forums
  • Announcements

    • Eric Newbauer

      Forum closed   06/30/2018

      PLEASE NOTE: This forum is closed and no longer moderated. Please visit https://www.studionetworksolutions.com/support/ for assistance with your SNS products. Follow Studio Network Solutions on Twitter. Thank you!


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About budy

  • Rank
    Advanced Member
  • Birthday 12/31/1966

Contact Methods

  • Website URL
  • ICQ
  1. Hi Marwan, just raise a support ticket with SNS - their customer support is really awesome. Whenever I had any issue with my keys the fixed that extremly fast. Cheers, budy
  2. I don't know what the relation to this forum topic is, but this is the way tcp/ip works anyway… The amount of bandwith is distributed based on several limits and usually is levels out between each connection. The only way to get around that is using something like a download manager, that spawns mutliple connections simultaneously and thus bends the rules to its favor. But as I said… I can't see where this is relevant to GlobalSAN.
  3. I'd rather start the other way round and take a look the the target's logs in the Free NAS box. I have used GS successfully and excessively on all versions of OS X since 10.5 and up to 10.8.2. Maybe it will tell you, why it reset the connection to GS.
  4. This may sound obvious, but I'd suggest creating a support ticket with SNS support.
  5. Hi, I finally updated all of my Macs on my home network to ML and thus to GS to .400. GS runs without issues on my MBP Retina 15", Mac Mini 2009, iMac 20" 2009 against my COMSTAR targets hosted on my HP N40L running Solaris 11 SRU 12.4. Speeds are, blazingly fast on my GbE network and everything runs smoothly, fast and stable. Cheers, budy
  6. HI Mark, sorry - but this is way too vague to reply in a useful manner. All I can grasp from your post is that you changed something in your network and now the initiators can't login to the one target any longer. Can you be elaborate a bit more on your setup? Cheers, budy
  7. If an iSCSI volume does not unmount it's usually not the fault of the target itself, but something on your Mac is still holding a lock onto the volume. Most often the fsevents.db or the Spotlight.DB are to blame when a volume won't unmount. It could also be a shell program that has cd'ed into the volume and thus holding a lock on it. You maybe able to determine the culprit by issuing a lsof | grep -i "<volume> as admin and see what files are still open on the volume. Cheers, budy
  8. Hi, I have tested my COMSTAR iSCSI targets on two of my Macs, a Mac mini 2009 and a MBP 3,1, 2.2 Ghz. The performance using GS v.5 seems to be the same as the previous GS initiators I used on those machines. Actually reading 4k or less blocks has always been slow, while transferring greater blocks shows a good performance: Sequential Uncached Write: 123,23 MB/sec [4K blocks] Uncached Write: 55,26 MB/sec [256k blocks] Uncached Read: 9,5 MB/sec [4k blocks] Uncached Read: 94,65 MB/sec [256k blocks] Random Uncached Write: 19,09 MB/sec [4K blocks] Uncached Write: 59,54 MB/sec [256k blocks] Uncached Read: 2,18 MB/sec [4k blocks] Uncached Read: 94,72 MB/sec [256k blocks] Transferring small block sizes always results in a speed impact, but as you can see, transferring bigger block sizes results in reasonable transfer speeds. Cheers, budy
  9. Hmm… running any iSCSI connection over a wireless network will be a huge challenge. It's not the wireless network in general, but most likely you will not be able to ensure the network quality you'd need for running iSCSI over it. iSCSI is extremely picky when it comes to timing and drop-outs. What makes it really worse is that the iSCSI protocol sits deep down in the OS and any hang on this does have the implications you're mentioning. I do have used GS over my WiFi connection at home, but I am not living in a crowded area, so I don't have to deal with network quality issues. Cheers, budy
  10. 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
  11. 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
  12. 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.
  13. Yeah - indeed. I will try to find out why the Aladdin HASP is installed in the first place… Cheers, budy
  14. Actually, without having access to the target hosts, it will be very hard to analyze the issues, you all are having with Synology and ReadyNAS units. All I can say is, that I don't have any issue with GlobalSAN v.5 and any of my iSCSI targets that are exported by my Solaris 11 Express/COMSTAR hosts. If the initiator does connect to the target, but displays no volume, there's not too many possible reasons, I guess: 1) the target somehow denies access to the actual LUN 2) the target doesn't export a LUN0 If you want to capture the iSCSI traffic using tcpdump, you should also consider installing Wireshark on your Mac and actually have a look inside the iSCSI protocol, as Wireshark comes with an iSCSI protocol analyzer. Try capture the session using tcpdump from an admin account like this: tcpdump -i <interface> -s 0 -w <where to save output> ip and port 3260 Afterwards, you should open this file with Wireshark and see, what really is going on, when the initiator tries to connect to the target. hth, budy
  15. Hmm, I wonder how you think to accomplish this? You'd need to have read/write access to all your data on each system, which requires a clustered file system, which GlobalSAN doesn't offer. GlobalSAN can be the transport for the clustered file system, but if you'd use HFS+ for that volume and connect to it from multiple Macs simultaneously, you'll hose your fs within seconds. Just a little heads-up… Possible clustered fs for OS X are: Xsan and SanMP both of them will you run $500+,- additionally to GS.