I bought a Drobo in June, 2008, and had it hooked up to a Windows XP PC and formatted NTFS. After expanding the capacity a few times, I ran into the 2TB NTFS max-volume size. Rather than splitting the drobo into multiple logical drives, I formatted it as EXT3 and mounted it to a Linux (Ubuntu) PC.

After the initial headaches of getting the Drobo formatted correctly, everything was great. The blue capacity lights reflected the current capacity correctly, and adding additional drives was no problem.

Then the Linux PC it was connected to started having problems.

The PC would freeze often, and after several hard reboots the ext3 journal got messed up. Being a relative noob in Linux, I assumed the drive was FUBAR, and eventually reformatted, losing several hundred GB of data.

As a remedy I rebuilt the Linux PC with some newer hardware (and better cooling), and put it and the Drobo on a UPS (although I’ve heard the Drobo actually has a small UPS on-board). For ~6 months this worked fine, and then I got ambitious.

I built a new media PC to replace the Linux system that the Drobo was attached to, and planned to use a ext2 driver for Windows to connect the Drobo to WindowsXP. At some point during this process, the ext3 journal has again been corrupted.

Since I currently have about 4TB of data on the drive, I am incredibly hesitant to reformat it. Instead I’ve done some homework into rebuilding the journal on a ext3 filesystem.

On running e2fsck on the Drobo, I get the error that the Superblock is corrupt, and suggesting to run e2fsck with an alternate Superblock. Running mke2fs (sudo mke2fs -n /dev/sdb1) gives a list of all the Superblocks, and eventually one of those blocks will allow e2fsck to do its thing (which usually takes about 6 hours if I’m on top of the prompts, running in the automated mode gives an error). Afterwards e2fsck says the drive is fine, but it still won’t mount. After rebooting both the Drobo and the PC, I’ll be back to the start with e2fsck reporting a bad Superblock.

FML.

Thanks!

USB works, but this is really suboptimal… ~22MB/s

When you reach the full amount of physical space the process writing to Drobo just hangs. I left the process hanging for some time and then deleted hard drive space and the process went on it’s way copying data again.

I posted my results on the Google groups site (posted above) if you care to read more of the tests I have done.

If by formatting you mean putting a filesystem on, eg HFS+, NTFS, EXT3 – then the answer to your question is that this is the OS’s responsibility, not the peripheral’s.

I’ve been using a Drobo v2 with Linux (Ubuntu) for a few days now; it works very well so far, I’m happy to say. It’s loaded with four Seagate 1TB drives. Although I only have ~3TB of usable space, the Drobo provides two 2TB partitions – so that either of the two EXT3 filesystems I’ve established can grow to 2TB.

I still don’t know what will happen if I fill one up then attempt to write more than 1TB to the other – I think that the OS will attempt to permit this of course, since it will believe that it’s writing to a 1TB partition. I’m guessing I’ll get a write error, or a hang – but Drobo support haven’t told me yet. Waiting for their reply.

I am looking to purchase a DROBO for a single user use who uses openSUSE 11.0 but from what I have read here, this product is not power consumer friendly ie ‘the drives must still be formatted after being inserted. Why can’t the Drobo assess what OS is using the thing and format the drive for that OS?
P.S: I have heard that the DroboShare is being discarded and Ethernet is going to be incorporated with FireWire/USB on the rear of the unit.

You might want to check out the drobo dashboard I wrote:

http://drobo-utils.sf.net

It also has a link to the google groups where there is a lot of talk about using Drobo’s under linux. Drobo’s actually work fine with 2 TB ext3 file systems. and the droboshare unit is an embedded linux.

google group:
http://groups.google.com/group/drobo-talk?hl=en

@koitsu – I believe Drobo uses storage virtualization and thin provisioning techniques (wikipedia has explanations if you need them). It does not present the physical disks to the OS – it presents a virtual representation of the disks. It needs to understand the filesystem in use in order to do this, thus the limitation on supported filesystems.

I bought a Drobo, 4 disks, 1TB each. In order to get a single disk (Drobo splits up the disks, what ever size you have into multiple 2TB drives) I created a logical volume group with the two drives (/dev/sdc , /dev/sdd) using pvcreate. Then created a Logical volume with lvcreate. After creating the filing system (ext3) I could then mount the volume. This gives me 2.5TB of disk space mounted on a folder.

I then spent a while filling the Drobo up, right up to 2.5TB – all the blue lights on and a red light on the top disk. I wanted to test its redundancy at this point so I pulled the top disk out, I could access the data with no problems. Pushed it back in again, it happily rebuilt its drive (it still complains about being too full at the end though). Having tested it I deleted all the data, unfortunately the blue leds did not go out. Presumably because it does not understand ext3 it cannot calculate the disk space used.

This has lead me to wander, if the Drobo thinks it is too full will it slow down deliberately as the manual suggests? Have not tested this yet as I only read this after I deleted all of the data that took 2 days to put on.

Although it looks quite nice I think in hindsight I would opt for a more standard external raid device (unless they come out with Linux support soon). Having said that if you are using it under Windows it seems to work without any problems.