Connecting Drobo to XServe via FW800

For what it's worth I had this problem with a Drobo S connected to a MacPro. It also failed the Apple Hardware test (extended). I also developed increasing directory corruption over time, particularly with time machine.

I may have found a solution to this by accident. I cleared it once, then somehow recreated when adding a drive, then cleared again.

WARNING - Data Robotics was not particularly thrilled with the use of the solution I found. It may lead to total data loss.

It's their method for a continously rebooting machine (a condition I had the first time I used it, but not the second) I was already planning on reformatting, but if you have data you need, they clearly don't endorse the method.

I'm not going to repeat here, it involves pulling the plug at a very specific time in the boot process. It doesn't have the warnings provided by the tech.

link is here

http://support.datarobotics.com/app/answers/detail/a_id/102/kw/drive%20reboots/r _id/100004/session/L3NpZC9IdGlROXFyaw%3D%3D

Unfortunately, the mini only has one network port. Otherwise...

I used our Drobo Pro in iSCSI mode. A direct connection between our Mac Pro and the Drobo.

However, the Drobo is rather crap, so it's just setting there now. I built a high capacity iSCSI target from a 6u case and am running GlobalSAN on the Mac, and iBackup on the target. Much faster, and NO ERRORS!

I have the exact same configuration and problem -- though I am using 10.7.1 Server now.

Wow, a long time has passed and I'm still seeing this error with my brand new DroboS, though it has yet to error out or corrupt anything. (It's still really early though. Given time, I'm sure errors or corruption are a real possibility.)

I've submitted a ticket to Drobo support and will update this thread with my final outcome.

...

Drobo to Drobo S copy via FW800 and an ongoing storm of "kernel[0]: IOFireWireSBP2ORB<0x0d62db00>::prepareFastStartPacket - fast start packet not full, yet pte doesn't fit" messages!
I have an old Mac Pro from 2006 running OS X 10.6.8 with 2x2.66GHz Dual Core Intel Xeon processors and 6GB of memory.
It's hooked up to one older Drobo (4 bay with 1TB drives per), and a new Drobo S (5 x 2TB) which was purchased on April 24, 2012.
I'm transferring about 2.56TB of data from the Drobo (firmware 1.4.1 [1.254.43359], serial number TDC082920341) to the DroboS (firmware 2.1.2 [5.33.44090], serial number TDD1151A0335) via a Finder copy, over FW800 at a snail pace (10-20MB/s) and seeing thousands and thousands of these errors in /var/log/kernel.log:
Apr 24 21:57:34 EmuraPrime kernel[0]: IOFireWireSBP2ORB<0x0d62db00>::prepareFastStartPacket - fast start packet not full, yet pte doesn't fit
So far, no I/O errors and the user-land Finder copy hasn't had problems.
I've seen threads like https://discussions.apple.com/thread/2405471 which are largely unresolved or point the blame at hardware.
What's the diagnosis here?
I have no problem giving you more detail, information, walking through a gdb session, etc. Just let me know. Frustrating to spend this much money and see a very, very basic operation show signs of problems. Don't even get me started on your data integrity in the face of dirty/hard restarts, or your strict filesystem support, playing games with the HFS allocation bitmap, and so on. Though to be fair and somewhat more balanced, your usability model is world class, top notch. Same with your industrial design. There *is* a reason I bought two of these!

I spoke too soon. It *seems* like as soon as I kicked off another Finder copy in parallel with the monster one which was taking place, I did start to see I/O errors.

[tons of them]

.

.

.

Apr 24 23:12:21 EmuraPrime kernel[0]: disk5s2: I/O error.

Apr 24 23:12:27 EmuraPrime kernel[0]: disk5s2: I/O error.

Apr 24 23:12:28 EmuraPrime kernel[0]: disk5s2: I/O error.

[EmuraPrime:~] emura% grep "disk5s2: I/O error" /var/log/kernel.log | wc -l

1005

[EmuraPrime:~] root# fsck_hfs -fn -c2g /dev/rdisk5s2

** /dev/rdisk5s2 (NO WRITE)

Executing fsck_hfs (version diskdev_cmds-491.6~3).

** Checking Journaled HFS Plus volume.

** Checking extents overflow file.

** Checking catalog file.

** Checking multi-linked files.

** Checking catalog hierarchy.

** Checking extended attributes file.

** Checking volume bitmap.

** Checking volume information.

** The volume DroboS appears to be OK.

So most metadata is okay (i.e. as much as fsck_hfs can confirm).

And while this DroboS continues to wildly spit out I/O errors in the log more than once a second, a check of some of the file data that was being copied at the time of the previous I/O errors is okay too:

[EmuraPrime:/Volumes/DroboS/Chris] emura% paranoia_verify_checksums.zsh *

Total_Files = 340

Mismatched_Checksums = 0

Matched_Checksums = 340

Unrecognized_Extensions = 0

Checksums_Not_Found = 0

( these are just raw Nikon NEF photo files where I keep the md5 embedded in the file name itself )

Also, doing I/O via dd(1) from the raw device is interesting depending on which size I use for the I/Os vs. hitting errors vs. performance.

Small I/Os (512, 4096, etc.) seem to translate into really bad performance (5MB/second), but no errors.

Larger I/Os get throughput up into the 30MB/second range, but I/O errors from time to time.

Much larger I/Os and we bail with I/O errors which make it back to user-land and dd(1) will bail.

Though throughout, looking at the I/O trace, it's clear that the Drobo has internal smarts and is "always trying to do something clever" on its end. Good stuff. Fun for debugging and troubleshooting. Looking forward to seeing what their technical support folks come up with.

Of course, I should have mentioned that to help rule out some hardware, I unplugged the DroboS and plugged the old SATA dock and 2TB drive into the same FW800 port. Did the raw dd(1) test and hit 65MB/second rates, sustained, absolutely no messages or errors.
[EmuraPrime:~] root# dd if=/dev/rdisk5s2 count=10000 bs=262144 of=/dev/null
10000+0 records in
10000+0 records out
2621440000 bytes transferred in 38.054525 secs (68886420 bytes/sec)
[EmuraPrime:~] root#

I just had this problem occur on my older Mac Mini and a Drobo S. The pair have been running for a couple of years with no hiccups and then I got a text message from my Drobo that it was rebuilding my data ... which completed suvvessfully according to a second text.

When I went to look at the console logs I saw several, perhaps hundreds, of the subject messages. No error on the Drobo Dashboard, no logs mentioning Drobo, just the FW errors.

And now it seems that they have stopped. Weird. OOPS! Looking again at the logs it seems to have started up again!

I eventually found that if I kept the i/o rate low enough, I could avoid it, but that was not an acceptable place to be. What I ended up doing is moving to eSATA. I still keep a tail -f going on kernel.log and still checksum everything (metadata AND data). So far, so good.

same problem here with a MAC PRO and A DROBO PRO.. everything is PRO but i get:

etc.. as soon as i copy data from the drobo pro.. for now the drobo support asked me to install a new driver for drobo.. will i loose all my data for this is a mistery !

I had this problem, over a year time frame they replaced the unit twice and ultimately it was fixed with a firmware update. I'm pretty sure it started with a prior firmware update, but since the damage is subtle at first it's hard to say. This was with a Drobo S, Mac Pro 2008, and FW (didn't see issue with USB).

I've updated firmware a number of times, never lost data.

For the most part it's bahaved fairly well since other than drive failures. It does seem more prone to directory corruption than my other hard drives though.

I can't say for certain what firmware fixed it, and I don't know if fireware versions are consistent by model. Looking back at my support logs it may have been 2.1.2 in Feb 2012. Currently on 2.1.5