Drobo Disconnects (part 2)

Earlier this month, I posted about one of my drobos apparent disconnecting. http://www.drobospace.com/forums/showthread.php?tid=972

In the course of the troubleshooting that followed, I have come to realise that said disconnection was the result of another problem, rather than a problem in itself…

What seems to be happening is that one of my two drobos slows down so much that whatever application is accessing it, treats it as having been disconnected.

Said apps include plex, vlc, and drobo dashboard.

My drobo’s are daisy-chained via firewire 800 to a mac mini, and i’ve since done all the expected cable testing - switching to new cables, just in case, and have determined that cables are not the problem.

Capacity of the drobo in question is around the 40%full mark, with all files being either audio or video files. About 1.5TB of that is my iTunes library.

Although the slowness issue sometimes manifests itself even when simply browsing through the folder structure, with a good number of seconds passing as each folder is opened, it is most evident when attempting to watch a high-definition movie. What happens here is that eventually - maybe after a minute, maybe after ten minutes, the video will freeze, maybe try to continue after a while, with playback being subsequently aborted.

The bitrate being used for HD playback (according to plex) is always under 14 MBit/s also, there is nothing else accessing the drobo during playback.

After the procedure as detailed in my previous post mentioned above, it seemed that the issue had been resolved. Yet, now, the same HD movie that a few days ago seemed to play fine from start to finish, suffers the same fate of playback abortion.

Can anyone guess at what could be happening here? Is the drobo itself faulty? The HD files play just fine on other 5400rpm drives.

I have no more ideas for solutions at this point…

I’d try this:
Connect your “media” Drobo to the computer via USB, leaving the other Drobo on Firewire.
See how performance is in that configuration.
Now swap the connections - put the “media” Drobo on the computer via Firewire, and the other Drobo on USB.

If a Drobo “drops off” in either configuration, it might be an issue with a drive (the Drobo is waiting for the drive, which is reallocating sectors) - send DRI your logs and ask them to check for the cause of the pausing/hesitation.

Hi Bhiga,

Thanks - I should have mentioned this - when I did the cable testing, I also tried connecting via USB. In all instances there was no change in performance.

The fuller drobo is apparently faster than the newer emptier drobo. - Copying a badly performing 5gb movie file from drobo to mac mini internal drive takes just over a minute with the old drobo, and close to ten (i stopped timing it after 7 minutes) on the newer drobo.

Today I ran the AJA system test as recommended by the knowledge base, and the read times on an existing mkv file in each drobo produces different results. On the old drobo, I get a respectable 31.7 MB/sec, while the same file on the new drobo gives a horrible 6.9 MB/sec.

However,on the new drobo, even in the case of a file that has a ‘good’ read speed graph with most activity between 30 & 38 MB/s, there are drops of performance down to near zero, and these last for quite a bit, with the average read speed pushed down to 19.5 MB/s

In the case of viewing HD movies, this graphing is mirroring exactly the behaviour of plex/vlc…

It is strange however that the behaviour varies with different files of the same size… Maybe the way each file was encoded/compressed is making a difference?

I’m going to see how to export the logs as you suggested in the meantime…

The compression type of the file shouldn’t matter as far as transfer rate goes, as Drobo doesn’t care or even presumably know about the file type. Of course, the viewing experience will vary greatly as inter-frame (temporal) compression relies on being able to access more data than just the frame-at-hand.

That said, on a DroboShare… the DroboShare itself does knows about the file type and may prioritize based on the type (you can see this in the smb.conf). I’m not sure if similar prioritization is made in your Airport Extreme or not.

If you haven’t let the new Drobo sit for a full 72-hours, then I recommend doing so, to ensure that it’s completely finished with its internal housekeeping. If it’s still performing poorly after that, then something sounds amiss.

The Drobos, are connected directly via firewire - no droboshare there…

It’s also not very new, as I’ve had it for a few months now - I got it in December last year.

It could very well be that after formatting, I didn’t leave it alone for a while, and started using it almost immediately.

I made one more test in the meantime - I took a badly performing file (the one I mentioned earlier) - copied it to another drive, deleted it from the drobo, and copied it back. The speed results after this were much faster. From the previous average read speed of 6.9 to a very fast 40.1 with only one drop visible on the graph.

I have let the drobo sit for a good 24 hours - much more in fact - last week, till i stopped hearing any disk activity. In fact the drives themselves felt quite cold before I used it again.

It would seem to me to be a fragmentation issue of some sort, but I’m only guessing, and other than leave it alone for three days as you suggest, there’s nothing else to do I suppose.

Very very odd.

Could be some kind of fragmentation issue, but Drobo handles its own defrag, so it’s really difficult tell anything more at this point.

Hopefully DRI support can shed some light based on the logs.