I reported a couple of problems to Tech Support yesterday, one being an unexpected Critical error, and the other the failure of the DroboPro firmware 1.1.3 install, plus two feature requests. Jeff came back quickly with a very helpful reply, which I think is worth posting:
Answering your questions and feature requests below inline:
“1. At 1:28AM, DroboPro reported a Critical error, and started a rebuild. By 7:00AM there was about 2 hours to go – an unusually short amount of time. What caused it, which disk drive was involved, and if only one sector had to be remapped, why did it take 8 hours?”
The Drive in slot 2/8 ( WD-WCASJ1573704 WDCWD10EACS-00ZJB0 ) had a issue at Sep 16 01:28:40 and did not respond like the drive was removed. Drobo started a relayout and then the drive came back at Sep 16 01:29:04. When it came back it was added as a new drive (the reason it took the longer relayout time)
You could leave the drive in, but if I was [sic] you, a drive not responding for 25 seconds is a pretty big issue and I would put it though a RMA process.
Also while you are at it, the drive in slot 6/8 is being watched closely by the Drobo and is on its way out also. ( WD-WCASJ0357545 WDCWD10EACS-00ZJB0 )
“2. I have not been able to manually install FW 1.1.3. Why? See my DroboSpace thread on the subject (Suite B).”
Read your post, Please try:
If you use an Apple Mac computer, the boot drive’s boot volume setting might be set to “case sensitive.” This setting prevents an update from seeing the correct case of the filenames in the firmware file directory.
Work around this problem by creating an additional directory called “updates” (with a lower-case ‘u’) in /Applications/Drobo Dashboard/
For example: /Applications/Drobo Dashboard/updates
Then try your update process again, and the process should complete.
Please check you have permissions to the Drobo (updates) folders
If the above is not the issue please try a different computer to do the update. (for updates if does not matter if you use a PC or a Mac as long as Drobo Dashboard is installed)
“3. Feature request. Please update Drobo Dashboard to provide specific information about ANY failure, or stop using log file encryption so we can determine this for ourselves.”
As for the diagnostics, they contain proprietary information so making them readable is not an option. However I do think that having a Techie Panel (or having more detailed results show up when an option is turned on) would be nice. I’ll send this up to Product Development.
- Feature request. Please update Drobo Dashboard so that it knows the difference between a failure involving only one drive, when dual disk redundancy is turned on, vs. the more dangerous case where there are no spare drives available.
I agree! This is in the works, no ETA when it will be finished / included in a future Drobo Dashboard.
The two drives in question (WD 1TB Green) have never caused a problem (or at least Drobo has silently fixed them), and are about 18 months old. When I called back and talked to Bryce, he suggested that I download the Lifeguard diagnostic program for the WD drives and run it to see what it says. Since I don’t have a spare slot available on my Mac, I will have to use an external USB adapter, and hope that works. What will happen if the diagnostics say that everything is fine is TBD at this point.
I did a hot swap with the drive in question, guessing (correctly) that the numbering starts on the left. I would have shut down the DroboPro, but after I uploaded about 1.5GB using CrashPlan, only to decide that I didn’t like their proprietary, encrypted format, I started another synchronization job using ChronoSync, deleted the old files, and emptied the trash to make room. I’m not just sure what I did – I think I must have somehow invoked the Secure Delete function. Anyway, that process has been chugging away for the past three days, and I am now down to 63 items remaining, from an original 200+. I assume these are folders, with lots of photos.
I can’t seem to cancel that operation, and I’m afraid to try the Force Quit option. So I did a hot swap of the first drive in question with a new 2 TB drive. At first, Drobo Dashboard estimated 65 hours, then 127, and now it’s down to 22/25/28/25/30/17/24 hours remaining. When it finishes, I will remove the second bad drive, and replace it with a second 2 TB drive, then recycle those drives in something that is less critical, after running the WD diagnostics.
But this indicates the need for a vastly improved diagnostic readout capability. Not only did I have to go to Tech Support to find out what happened to the first drive, but if Jeff hadn’t been so conscientious, I would have never known that another drive was becoming problematic. Murphy’s law didn’t strike in this case, but it certainly could have, with a double drive failure. And after I did the hot swap, for a while Drive 1 lit up red, and everything else green, before returning to the alternating green/yellow sequence. Be still, my heart!
I’m not entirely sure what SMART statistics are available, or what they would say, but certainly any suspicions that the Drobo firmware has needs to be reported to the users – unless Tech Support would like to camp out in my office!
Since the 1.1.3 firmware seems to apply to VM ESX primarily, I’m not in a rush to install it, so I will wait until everything settles down before fixing the other problem. However, the problem would appear to be twofold.
First, the directory is indeed called “Updates”, and not “updates,” and I didn’t create it, the Drobo installer did. And I have no idea how to see or change the boot drive’s boot volume setting to be case sensitive or not, or what other problems that might casue (or solve).
Secondly, the permissions are set to give my Admin account Read/Write access, but not my limited user account else, even though I installed the Drobo Dashboard in my limited user account (so that I wouldn’t have to log in as Admin just to get the iSCSI initiator to kick off). And I can’t run the Dashboard as Admin, because it wasn’t installed there – Catch22!
This is yet another example of horrendously bad coding and QA practices, by programmers and testers who always assume that everyone runs in Administrator mode, just because they do. WAKE UP, DRI! At least some Mac users actually care about security, and not allowing botnets to run on their computers!
It is inexcusable to merely say, “Firmware update failed” without providing some clue or reason why. Not only does this greatly irritate the customer, but it causes increased Tech Support costs, and hurts their bottom line. The VP of Engineering ought to ream some new orifices in their programming team, and if he doesn’t understand the issue, then the CEO needs to look for a new VP.
Although the Drobo firmware occasionally suffers from less than Outstanding performance, in general it is pretty solid and reliable. The functionality of the Drobo Dashboard, however, is well below par, and ought to be re-architected and rewritten from scratch.