Drobo + DroboShare + MacOS + SMB v AFP. Trouble?

[font=Verdana][size=medium]
All,

Thanks in advance for any help I can get on the following issues! I’m deep into a project that demands better performance from my Drobo/DroboShare. Here goes:

  1. My combination Drobo + DroboShare (all with latest firmwares), is sitting on a gigabit Ethernet network with no server. 98% of the time, the two primary users access Drobo to backup and retrieve files on a daily basis. Both users are Mac (OS 10.5.8 and OS 10.6.2).

  2. Drobo w/ DroboShare is configured with 3 1TB drives and, as of yesterday, a 4th drive (1.5TB was added). We see 2 volumes, each with 2 TB capacities. To date only .3 TB of storage space has been used. The SATA drives are all Seagates.

  3. The files backed up on Drobo are the type seen in graphic design – InDesign, Photoshop, Illustrator files. The file architecture is folder deep; sometimes (starting from the root) about 5 to 10 folders deep. This will never change. File sizes can range from negligible to hundreds of MB. Folder sizes can range from negligible to a couple of GB in size. Folders can consist of sub-folders and/or files at almost all levels.

  4. We’ve owned Drobo + DroboShare for six months. It’s never been moved, it’s in a cool space and sits quietly. Both users automount Drobo volumes using SMB protocols (versus AFP). I am very concerned that this may be the source of our Mac environments problem. But read on…

  5. Recently, the second user in the system (the one with OS 10.6.2) has experienced an increasingly ADVANCED case of sluggish access to Drobo w/ DroboShare. So sluggish that this user cannot perform her work. Opening folders may take minutes (up to 10 minutes). Backing up may take hours. Where previously access was reasonable for a network-attached backup system. Comparatively, my Mac (OS 10.5.8) accesses Drobo w/ DroboShare relatively quickly although I too am noticing a slowdown as well.

  6. The situation has deteriorated so much that the second user is now getting an error message that states: "The Finder can’t complete the operation because some data in “FOLDER NAME” can’t be read or written. (ERROR CODE -36) This user now must manually backup her data. I am testing further by disconnecting Drobo w/ DroboShare from the network and connecting, via Firewire directly to the user with Snow Leopard. I’m betting there will be no problems…

  7. Why is this performance degredation happening? I’m mortally afraid that using the SMB protocol (and how Drobo interprets that protocol) is putting gigabytes of data (particularly PhotoShop, Illustrator, and InDesign files) at huge risk (e.g., no resource forks). Obviously, this is not what we bought Drobo for.

  8. And while I have your ear (so grateful!), when I added the 1.5 TB drive yesterday, Drobo correctly identified it as a new volume that needed to be formatted. I gave it a SHORT name and said yes! Somehow, the name was truncated to one letter. So, I go to ADVANCED CONTROLS–>TOOLS–>RENAME DROBO AND VOLUMES to rename the new volume. Only the option to rename either of my two volumes is grayed out. I can only rename Drobo. What gives? How do I correct?

Please help…

Arkadia[/size][/font]

I would recommend updating your OS to 10.6.4.

I would also recommend directly connecting your Drobo to one of your macs and running Repair Disk from Disk Utility. We recommend doing this at least once a month to ensure the integrity of your date.

Follow directions on this KB
http://support.datarobotics.com/app/answers/detail/a_id/405

Thanks for the prompt reply. Do you mean updating the 10.6.2 client to 10.6.4? Or both clients?[hr]
One more thing. My folders and files are filled with the potentially illegal “_” (underscore) character. Clearly, SMB does not care for this character. Why can’t I use the AFP protocol and how do I make that change? Thanks.

The 10.6.2 to 10.6.4.

10.5.8 is the latest update for Leopard.