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 Msteel

  • Rank
  1. So no official word? I have done some digging and I have seen reported that the 8506 series can have: * 2TB per (raw) array max * 2TB per drive max, larger drives will be truncated. * 2TB total MAX with RAID5 since all disks must be in the same array for RAID5. So, it _may_ be possible to set up each controller with 8x1TB drives as 4x2TB RAID1 arrays. If this scenario works I could get 16TB raw, 8TB capacity out of this controller. What is unclear is whether I actually can have 4 arrays per controller. Since the douments for the 8506-12 (12-port verion) say it can handle up to 12TB this might work.
  2. We have an older X16 with 4TB raw capacity using 16x250GB drives. With significantly larger drives easily avaialble these days is it possible to increase capacity by swapping drives? Here is the information on the RAID controller (of which there are 2 in the box): Model: 8506-8 Serial number: F17700B4180881 PCB revision: Rev5 A Chip revision: 3.20 P Chip revision: 1.30-66 Firmware revision: FE8S BIOS revision: BE7X Monitor revision: ME7X Number of ports: 8 And the flashware version is WSB 1500i MR4
  3. Thanks for that info. If I need to make changes I'll look into using that. But since I've got the Applescript pretty much working now, I think I'll leave things alone.
  4. If it were not for profiles I think I would be pulling my hair out more than I am. Since the SANmp Client GUI is not written as a scriptable application, I am having to go through all the back doors, like telling System Events to click menu item "Log In" of menu "User" of menu item "User" of menu bar 1. And, the GUI doesn't even map the standard "open" command to the "Load Profile" command. If I ask the SANmp Client to "open" a profile file, it tells me it does not support this kind of file. So instead I am simuating key presses to bring up the "Load profile" dialog, etc. The irony of that is that I was a proponent of splitting the GUI and the CLI. The advantages I saw to that were that you could mount drives at boot without having to have somebody logged into the Mac to get a GUI. But if I had known that it would mean one or the other then I would never have asked for it.
  5. We are transitioning from PPC/Tiger to Intel/Lion and so have moved to SANmp Client 4.0 from whatever version we had been using. On the old machine we mounted drives at login using a script and the CLI. The previous behavior was that the CLI launched the GUI. Once I found out how to make the script hide the GUI when we were done this worked well. If we wanted to mount an additional drive later, we could pull up the GUI and do it. The new version seems to behave differently. It appears that the GUI and the CLI are mutually exclusive. If the GUI is open the CLI will not log in, and if the CLI is logged in the GUI cannot. Is there no way to mix and match the GUI and CLI anymore? Is it possible to use Applecscript to load a profile or something at least?
  6. Was the telnet server added in a later version of the Wasabi flashware? Our unit is running on an image listed as version "WSB 1500i MR4." from 2005, and the "Remote Console" tab is not present.
  7. I'm not sure this will be a help, but perhaps it will. For a while we were seeing appeared to be a similar problem on two of our three workstations. The GlobalSAN gui app would crash, although we could still connect to persistent targets. This was on an Intel iMac as well as a PPC Power Mac, both with different versions of Tiger. After trying everything we knew to do - deleting plists, uninstalling, reinstalling, rebooting, all in various combinations - we had no idea what else to try. Since we could still connect to our disks we reluctantly just left things as they were. After I saw this thread I remembered our problem and went to verify the details of our problem machines. But now the app runs just fine. I don't know whether to be frustrated by this or happy. I do not know of any system changes that have been made to these machines. The only thing I can think of that might have affected this is that I believe we had a power outage some time ago and at that time all our workstations as well as the target would have been powered off, and then brought back up in an orderly fashion. Perhaps bringing everything down and then back up again might be something to try.
  8. Update - We stopped having this problem quite some time ago, and never really found out exactly what was going on. As best as I can tell, one of our workstations was bringing down the X16 somehow. It was a Windows client that had never been stable when accessing the SAN. For that reason and others, we never ran SANmp on it anymore (although the Microsoft iSCSI initiator was still there). It was a painless solution to pull the plug (literally - the direct network connection to the X16). From that day we have been trouble free.
  9. These are the versions we are using on our various workstations: X-16 version 4.8.1 PowerMac G5 OSX 10.4.8 * GlobalSAN iSCSI v. 3.0 build 1150 (crashes now when I try to run it, it didn't use to do that, persistent targets still connect) * SANmp Admin 1.6.0 build 16 * SANmp Client 1.6.0 build 16 iMac G5 OS X 10.4.9 * GlobalSAN iSCSI v 2.0.0 build 1119 (doesn't crash) * SANmp client v 1.5.0 build 33 iMac Intel OS X 10.4.10 * GlobalSAN iSCSI v 3.0 build 1150 (this one crashes too, but persistent targets still connect) * SANmp Client v
  10. We've had some trouble lately with out X16. A workstation (OS X) will hang trying to access it and the web interface to the GlobalSAN will be sluggish or totally unresponsive. I have managed to get a log file a couple of times (log files seem to disappear upon reboot), but rarely can I restart it through the web interface. Here is a sample log file just before the crash: Jun 4 12:17:49 X16 kernel: twe1: port 2: sector repair occurred Jun 10 08:07:32 X16 utarget_fsdisk: UNKNOWN SCSI OPCODE 0x1b Jun 10 12:57:44 X16 kernel: twe1: port 2: sector repair occurred Jun 10 12:58:08 X16 utarget_fsdisk: Timeout of iqn.2005-03.com.studionetworksolutions:mac-1667677261,i,80534e530000 from iqn.2000-08.com.studionetworksolutions.globalsan:x16-2,t,0017 cid 0 Jun 10 12:58:08 X16 utarget_fsdisk: Timedout iqn.2005-03.com.studionetworksolutions:mac-1667677261,i,80534e530000 to iqn.2000-08.com.studionetworksolutions.globalsan:x16-2,t,0017 cid 0 stats: Recv: 4123293044 b 1365537 PDUs Sent: 11289155084 b 2026303 PDUs Jun 10 12:58:25 X16 utarget_fsdisk: Timeout of iqn.2005-03.com.studionetworksolutions:mac-1483403293,i,80534e530000 from iqn.2000-08.com.studionetworksolutions.globalsan:x16-1,t,0005 cid 0 Jun 10 12:58:25 X16 utarget_fsdisk: Timedout iqn.2005-03.com.studionetworksolutions:mac-1483403293,i,80534e530000 to iqn.2000-08.com.studionetworksolutions.globalsan:x16-1,t,0005 cid 0 stats: Recv: 13407536976 b 2726667 PDUs Sent: 23853262808 b 3379904 PDUs
  11. We currently have 4 workstations connected to our X16. Each has two adapters, one for our LAN/Intranet and one for the X16. This is good for the workstations since LAN traffic is separate from SAN traffic. But there are a few places we'd like to have access to the SAN where it is impractical to have a dedicated line. Because of this I'd like to connect one of its adapters to our LAN switch and give that adapter an IP address on the LAN. Our IT department wants to make sure that we can disable routing between X16 adapters so we won't have routing problems like multiple routes and loops. It appears that the HTTP interface to the SAN doesn't allow changes to this setting, and my attempts to test whether routing is enabled seem to indicate that it is not enabled. But I wanted to get a more expert opinion on that, from those who know better what's going on inside the box.
  12. I agree. It is only on Windows that I have encountered this limitation. Unfortunately, it is on Windows that native file sharing is most useful for us.
  13. Well, I have verified that this setting is correct. I can't say for sure how it was set during the outage, although I don't think I've ever set it to "disabled." We'll see what happens next time. Or I'll do a controlled test to see what happens if the UPS runs out.
  14. Thanks for your response. It backs up my conclusion that the only way to make this work is to have a computer that has an administrator permanently logged on. I am aware that admin privileges are required to mount SANmp drives. Even without reading the manual you quickly find that mounts fail with an error from a non-admin account. But even you have multiple admin accounts used the machine, there would be problems sharing volumes because of the nature of the SANmp GUI. Standard local drives are mounted at system startup, so they are available for sharing even if no one is logged on to the machine. But because the SANmp GUI runs as a user process, it shuts down at logout. This means that a drive is not available for sharing unless an admin is logged in locally.
  15. Well, let me say first off that our X16 is on a UPS, as it should be. But there have been a couple of times when nobody could mount SANmp volumes and when I investigated, the iSCSI was disabled. This last time was after a known power outage, and I suspect that the UPS ran out, the X16 went down (in a disorderly state) as a result, and came back up with iSCSI disabled. So, does anybody know: 1) If there's a way for the X16 to find out that the UPS is about to go down and shut itself down nicely. 2) If there's a way ensure that iSCSI comes on in an enabled state after a shutdown. I believe that iSCSI was set to be enabled at next startup, but couldn't say for sure... Matt