Drobo Disconnects

I have two 2nd Gen Drobos daisy chained via firewire 800 to a mac mini.

Recently I’ve noticed that the one NOT connected directly to the mac is disconnecting at will and, it would seem, randomly.

When this happens, any program accessing the drobo, such as iTunes, will hang and need to be force-quitted. Also, the Mac will not shutdown or restart without the power button being physically pressed for a hard shutdown.

I’ve also only recently had the need to leave the mini powered on for a few days without powering down, which could be why I noticed it happening now and not earlier.

Both drobos, mac and drobo dashboard are using the latest firmware and software.
Both drobos have 4 x 1.5TB Western Digital EADS drives.

Is this a known problem? Are there any solutions?

Have you tried a different FW cable?

If you don’t have a spare cable try swapping the cable between the two Drobo units. If the cable is dodgy then both units should drop off as the cable would then be between the first Drobo and the computer.

It makes sense, but I doubt it’s the cable as the unit returns to normal after a reboot of the mac, without me physically touching anything other than the mac’s power button.

Also, since my post, I seem to have narrowed the problem down to multiple files being written and read to simultaneously.

I recently started using an application that does this, and thinking about it, that’s when the problem began. In fact, I’ve since drastically limited the number of files that are being accessed simultaneously, and so far have not had any problems - it’s been 48 hours give or take now…

I’ll eventually slowly increase the file number to see at what point the drobo hangs.

Still, if this is indeed the cause of the hang, i doubt it’s normal or expected behaviour… or is it?

It’s still worth swapping cables, if nothing more to confirm that it is definitely not the problem.

I agree that you should replace your cables - firewire 800 cables tend to be quite stiff and place a strain on the connectors.

I’ve found that the orange LaCie cables work really well - they’re flexible and tend to not place a great deal of strain on the connectors.

Strain over time can do weird things to materials - I have a MacBook Pro 17 (early 2008), and over the years the Kensington Security Slot lock which I use at work (steel) has eaten its way through my MacBook Pro’s aluminum slot so that it doesn’t provide security any more - it can be worked out without unlocking the lock.

I haven’t tried changing the cable, as, so far, the problem seems to have gone away.

I’m increasing the number of files being accessed simultaneously, and still have not had a hang.

Maybe one of the initial files was corrupted in some way or another…

I’ll keep increasing the number of files and see if anything goes wrong.

Yes - The second drobo (the one being accessed) hung when I increased the number of files.

These files are large - 3 to 12 gb and being written to as well as read from simultaneously.

I suppose there are some limiting factors, not least of which would be speed and drobo’s redundancy protection that impede this workflow.

I’ve put down the number of files being accessed to a level which seemed to be fine for a couple of days.

The redundancy (fault-tolerance) is transparent to the system, so it shouldn’t be an issue.

Reduced speed due to fullness could be. How full is your Drobo?

It’s 45% full.

I realise I could have been clearer in describing the ‘disconnect’ bit…

The drobo ‘hangs’ rather than disconnects. Mac OS still sees the drobo as connected, though it is inaccessible. It does disappear from drobo dashboard though.

So far though, with the accessed files back down to yesterday’s level, it’s working fine.

That’s very odd. Being that seems to be specifically based on number of files, it points a bit more toward the OS or filesystem rather than the Drobo itself.

Have you run a disk check on the volume’s filesystem? I’d start there. I’ve had Windows do funky stuff when the filesystem had errors. It’s likely the same on Mac OS.

It seems I’m not able to do that with disk utility since drobo dashboard is controlling the drobos…

Drobo Dashboard doesn’t need to be running in order for the Drobo to be mounted.

I know, but mine are formatted using drobo dashboard, so they can’t be accessed safely otherwise.

Again, even if you formatted your drobo with dashboard, you do NOT need dashboard in order to mount your drives.

If your drobo is not mounting but disk utility can see them. I would see if FSCK is running in the activity monitor.

I thought dashboard had to be running… something to do with the drobo being seen as a 16TB drive when it only has 6TB of space in reality. No?

I ran activity monitor, and searched for FSCK, but it was not running. I have no idea what FSCK is by the way…

Meanwhile, though the drobo did not hang anymore, it’s running really really slowly. I cant play any video files off it, they just stop. It’s still at 44% full.

I power-cycled several times, but even after a fresh start, video playback is a no no.

Could it be doing some relayout?

The first drobo still works fine, and it’s at 72% capacity.

Then run repair disk from Disk utility.

FSCK is file system check. If that’s running, it will prevent the drobo from mounting. It’s like chkdsk on windows.

You would go into activity monitor, select “all processes” from the drop down menu, then under process name column look for FSCK_

Drobo’s Thin Provisioning (the thing that lets it look like a larger than the physical storage) is done solely in the hardware. Drobo Dashboard is just for changing settings, email alerts, pop-up alerts, and the usage graph.

It’s definitely convenient and useful, but not required for normal Drobo operation.

Plus the indicator lights on the front of the Drobo tell you everything you need to know
% used/free space, fault lights, etc.

As you can see here
the speed of the Drobo is different depending on how much rest the Drobo had. Pay special attention to the note halfway down: “Note: It is very important to let the Drobo rest after format, and probably after writing large amounts of data. I did not even reach half the speed when I started writing directly after format.”

I’m not sure what it is doing, but it might be some internal defragment and/or relayout process. This is NOT shown by any LEDs at the Drobo but you will clearly hear the drives working. I would give your Drobo a day or two to rearrange the data and then make your tests again.