I called Drobo customer support. Actually, I called Drobo sales, since there doesn’t seem to be a separate customer support operation. The salesperson was very helpful. He said that normally they tell customers with disk failures to go to the manufacturer for replacements, but, since I’d had four out of five fail, he’d call the distributor and have them arrange for a swap.
After two days, I haven’t heard from the disk distributor . Maybe next week. However, the big brown truck brought three spare 2 TB drives from Amazon. I pulled one of them out of its box and plugged it into the FS in the space of the most recently failed drive. After about a minute the Drobo was happy and gave me four green disk lights. I had already been loading data onto the array, so I continued.
I can now give you some performance numbers. Using fairly large (between 30 and 100 MB) files, and Vice Versa with the cyclic redundancy check turned on, the sustained transfer rate to the FS appears to average around 28 megabytes per second, or 220 megabits per second. This is only slightly better than the performance that I’ve observed on the USB-connected Drobos. With shorter files, things get worse. We can’t blame the Drobo for all of this; I usually see performance about half again faster with server-to-server transfers over gigabit Ethernet.
As an aside, it seems to be a sad verity that local area network transfers operate at about 1/3 the raw speed of the media. I remember, more than 20 years ago, been disappointed that Ethernet transfers over the 10 megabit per second links of the late eighties, seem to top out at about three megabits per second even if other traffic on the network was minimal. Now, even with switches rather than contention devices mediating the transfers, the ratio hasn’t changed. I blame this on a continuing reluctance of system designers to offload the computationally intensive portions of the protocol stack to dedicated devices.
It’s interesting that transfers of really big files, like operating system partition images, proceed at a average rate substantially lower than that of 100 MB files, and that the rate varies widely over time. I don’t have an explanation for this. In previous conversations with the Drobo support staff they have mention that the Drobo firmware looks at the file characteristics and optimizes the disk layout accordingly. It may be that the processing necessary for long files uses up a lot of cycles in the Drobo processor.
During my initial setup of the Drobo FS, I found that there was no way in the Dashboard to join the Drobo to the Windows domain. I asked the tech about that. He said that the Drobo FS could not be part of Active Directory, even though various windows server operating systems were listed as being compatible. This was a surprise to me; I have not been able to find it explicated anywhere on the Drobo web site. My previous experience with network attached storage devices was with various Buffalo boxes; they all had pretensions of being Active Directory compatible, even if in practice they were somewhat balky.
badbob001 says
If you’re going through a server, you might as well get a DAS like the Drobo S to get better performance.
Jim says
You are absolutely right. When I bought the FS, I didn’t understand its lack of compatibility with Active Directory. Had I known, I’d have gotten the S. Going through the server is just making the best of a less-then-perfect situation.
Jim
Allen says
There’s a 30-day return policy, I believe. If you aren’t satisfied…better get an RMA quickly if you want the S (if there’s still time).
Jim says
Good point. Too busy to swap it out now. Inertia: a terrible thing…
Jim