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

Everything posted by Msteel

  1. 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
  2. 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.
  3. 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?
  4. 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.
  5. 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.
  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. 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
  8. 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.
  9. 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.
  10. 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
  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, 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
  14. 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.
  15. 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.
  16. Vote for new SANmp features

    I just found the forum although it appears to have been here for some months. Here are my $0.02 This could be nice, although in our situation we often have users mounted all the time but not always at the workstation... OK, this might be hard enough to not be worth it. But I'll mention it anyway. The current implementation requires the GUI to run to do anything. I suspect this is inherited from OS9 days and might be hard to get rid of unless OS9 support goes away. But it seems like a cleaner implementation would have all the real work be done outside the GUI by a service process or a driver. The CLI and/or the GUI would then access this driver to do what needs done. This could provide the following advantages: * A workstation user should not need administrative privileges (admin privileges are required in Windows in my experience) * It could allow drives to mount at startup rather than login. This would enable native sharing regardless of the workstation's local login status. * The GUI would not need to run or be visible in scripted situations. This is largely cosmetic, but in Windows it's irksome to always have the GUI on the taskbar and if you accidentally close it you unmount your drives.
  17. Jerome, This would be useful for us as well, but I tried some time ago and couldn't get it to work reliably. I m interested in more details about how you got it to work. Do you have a PC dedicated to the sharing? Our organization's network is large and slow (for audio), so our SANmp network is physically separate from it, and has a separate subnet. We have few enough audio workstations that each has a separate port on the X16. Machines which require access to both have two network interfaces. I connected a general-purpose XP box (not an audio workstation) to the audio network as a bridge. I could then mount SANmp drives on that machine. Sharing on our windows network seemd to work. But I could not get this to work on a regular, automatic basis. These are the limitations I ran into: * Mounting SANmp volumes requires admin privileges. * Logging out of the admin account closed down SANmp client and unmounted the volumes. * I could not leave the admin account logged in since others needed to use the workstation. I tried to solve this by mounting the SANmp volumes with a startup script, which ran as admin (through group policy). I also had a shutdown script that ran much the same way to unmount the drives. I suspect that this was the cause of many of my other problems since the SANmp software was obviously not intended to be run in this way. The first time a volume was mounted this seemed to work, but the unmount did not seem to be clean and subsequent remounts were hit and miss. I also had a terrible time getting drive letters or mount points to be consistent, which created a lot of problems since I was scripting this. I also had at least one time that the bridge machine crashed while accessint the shared drive. So I finally concluded that I'd need to have a dedicated machine to perform this task and gave up. Since you say you were able to do this and it works well, I am interested in knowing what you did. Msteel