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!


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Francois

  • Rank
  1. We have had SANmp since 2005. Over they years we expanded to 10 MAC seats and 20 volumes spread over six fibre channel controllers in three arrays. Largest volume is a newly created 4way stripe with 6.8TB space. Total san space is about 70TB. We found SANmp volumes to be very stable, but have still lost some volumes to to hardware malfunction (one UPS failed in a power failure - leading to one 3TB volume lost) and also to user mistakes (leaving the SAN plugged in while installing a fresh Mac OS)... Disk failures and controller failures generally don't cause data loss - touch wood. A serious controller failure writing junk to disk can also cause big problems, but we have not had such a problem in the 7 years on SANmp. We have always been able to back up critical volumes to other volumes on the SAN, but our space requirements grew exponentially since clients shot on camera cards and want to keep footage forever... We feel DLT tape is expensive and slow. If we lose a whole volume, it will take days to restore from tape. Backing up to firewire disks work ok but they become unreliable when the firewire chains get too long... We resorted to archiving to 2TB WD green disks (always two copies...) before deleting stuff, but keeping a daily backup that way is totally impractical. What do you use for backing up critical volumes? Hardware and software? Would you recommend it? Thanks Francois
  2. Snow Leopard Support

    Hi Ryan I am running a test system on Snow leopard with FCP 7. I know I shouldn't, but just could not wait. One system only, on our 11 seat Leopard SAN. I have had some strange issues with sanmp: Most of the time sanmp ( works fine. - once I had 12 "mac os boot" icons appear on the desktop. Went away ater a reboot. - sometimes sanmp GUI cannot connect to the sanmpTool app. Quit GUI and restart solves it. - this morning the sanmp tool used 100% CPU for about 10 minutes and then just appeared to fix itself. Whoooo - scary.... Am I taking a huge risk? I suppose I should rather wait until you have an updated sanmp ready... Regards Francois
  3. Hi Dan We were running V1.6 and could not get V1.7 to be stable on our systems. We have 10 seats, almost all are G5's. Two drive arrays - ADTX and Raidtec. However, we have found V2.0 to be very stable on our systems. We have been using it since about the start of the year, and have not had any issues that we could attribute to SANMP V2.0. We didn't have to re-format our arrays. Regards Francois
  4. Vote for new SANmp features

    Hi Ryan Is there still an autosync feature? I can't find it... There is still one reference to it in the help file - in troubleshooting - but I cannot find where to set it up. Regarding the local profile - it does not remember the read/write status of each volume. It mounts all previously mounted volumes in read-only mode, then I have to unmount all my write volumes and manually mount them again. Regarding parallelisation: All mount/unmount operations happens sequentially in sanmp. Is that an OS X limit, or would it be possible to mount multiple drives in parallel when the user requests it? I'm looking at the CPU utilisation and disk activity when mounting and when waiting for a mounting timeout on a disk that was not properly unmounted - very little CPU, almost no disk data transfers. About 300 disk reads/second - tiny data packets. So the CPU would be able to handle it, and the bandwidth is available, can you mount many volumes in parallel? Thanks Francois
  5. Vote for new SANmp features

    Feature requests: 1. Create a list of volumes, with corresponding read-write options, which auto-mounts for each user that logs in to SANMP. This would just outomate a repetitive chore that happens each time the system starts up, or when a new user logs in. We have created a stand-alone program that does this through the CLI, but it would be better if this could be included in sanmp. 2. Decrease the time it takes to mount a volume that was not unmounted properly. Though this happens infrequently, a post-crash restart does waste a lot of time to go through each volume's error-checking time seperately. We have 16 volumes, and in most cases mount about 12 of them... Alternatively, if you can not decrease the mounting time per volume, could you mount all drives in parallel, so the error-checking time runs in parallel and not sequentially? 3. Synchronise seems to work pretty good in sanmp version 2. You used to have a auto-sync which would sync every X minutes years ago, but we quickly stopped using the autosync because it caused dropped frames. Would this feature work without causing dropped frames if re-implemented on the newer, more robust operating systems? Regards Francois