Setting up a Drobo in Linux: The Right Way

Submitted by litrik on

After I wrote my previous blog post with instructions to set up a Drobo in Linux, I noticed that the write performance was really bad and when I deleted files the LEDs showing the used space would not go out. Clearly something was not set up correctly.

After reading a fairly old (password-protected) post in one of the Drobo forums that mentioned "If you do it that way, then Drobo will not be able to reclaim deleted blocks. The described method bypasses Drobo's management." I decided to start all over.

The goal of my setup is to get my Drobo up and running in Linux, using an ext3 file system and with a LUN size larger than 2TB. The large LUN size is necessary if you don't want to end up with multiple devices once your Drobo disk space exceeds 2TB.

Here we go:

Before you insert your drives into the Drobo double check the drive's jumpers and make sure that they are set to run at 3Gb. See this Drobo FAQ. My Seagate ST31000340AS Barracuda 1TB drives were originally set to 1.5Gb.

Insert your drives, connect the USB2 cable and connect the power cable.

Install drobo-utils. I ran into a couple of segmentation faults when using version 0.3.3 so I have used the trunk version from subversion where this was fixed. In the meantime the 0.3.3.2 binary download also contains the fix.

Use the drobom command to set the LUN size to 8TB:

$ sudo drobom setlunsize /dev/sdd 8 PleaseEraseMyData
8 PleaseEraseMyData
You asked nicely, so I will set the lunsize to 8 as you requested
set lunsize to 8 TiB
Done... Drobo is likely now rebooting.  In a few minutes,
  it will come back with the new LUN size.

Use parted to set the disk label to gpt and create a partition of 8TB:

$ sudo parted /dev/sdd
GNU Parted 1.8.9
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel                                                          
New disk label type? gpt                                                  
(parted) mkpart ext2 0 100%                                               
(parted) quit                                                             
Information: You may need to update /etc/fstab.

Use fdisk to verify the disk and partition size:

$ sudo fdisk -l
WARNING: GPT (GUID Partition Table) detected on '/dev/sdd'!
The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdd: 8796.0 GB, 8796093022208 bytes
255 heads, 63 sectors/track, 1069397 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1      267350  2147483647+  ee  GPT

Format the 8TB partition:

$ sudo mke2fs -j -i 262144 -L Drobo -m 0 -O sparse_super,^resize_inode /dev/sdd1
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=Drobo01
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
33554432 inodes, 2147483639 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
65536 block groups
32768 blocks per group, 32768 fragments per group
512 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848, 512000000, 550731776, 644972544, 1934917632

Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 25 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Mount the Drobo partition:

$ sudo mkdir /mnt/drobo
$ sudo mount /dev/sdd1 /mnt/drobo/

Check the available diskspace:

$ df
Filesystem            Size  Used Avail Use% Mounted on
...
/dev/sdd1             8.0T  129M  8.0T   1% /mnt/drobo

Add the following line to /etc/fstab to mount the Drobo automatically during startup:

/dev/drobo/drobo /mnt/drobo ext3 defaults,errors=remount-ro 0 0

My Drobo has been set up like this for more than a week now and so far it has been running great.

I have also tried a couple of other things but I couldn't get them to work correctly:

  • When I connected my Drobo using a Firewire cable, the 8TB device always showed up as a 2TB device. I don't know why. In the end I decided to connect the Drobo using a USB 2.0 cable instead.
  • I originally tried to set the LUN size to 16 TB but after doing that parted was unable to set the gpt label. Parted seemed to go into an endless loop using 100% CPU.

Topic: 

28 Comments

Thank you! What a great

Submitted by Tom on

Thank you! What a great post...

I received my drobo yesterday (same hardware as yours: drobo v2 and 2x Seagate 1TB) and set it up according your tutorial. So far linux is showing me 8TB and everthing is fine.
Then I copied a bunch of data on the drobo (~40 GB) and after unmounting and mounting again I got the following errors:

[24669.144336] EXT3-fs error (device sda1): htree_dirblock_to_tree: bad entry in directory #2: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0
[24953.756337] EXT3-fs error (device sda1): ext3_check_descriptors: Block bitmap for group 1 not in group (block 0)!
[24953.760342] EXT3-fs: group descriptors corrupted!
[25375.465954] EXT3-fs error (device sda1): ext3_check_descriptors: Block bitmap for group 1 not in group (block 0)!
[25375.471222] EXT3-fs: group descriptors corrupted!

After that point, I could not mount the partition anymore.

Have you experienced the same problems?

In the drobospace forum I read that the max LUN size supported for linux is currently 2TB. That's why I am just repeating my tests for a LUN size of 2. Let's wait and see...

I agree, a great

Submitted by Robert on

I agree, a great post.
However, what you just stated is correct.

I followed the instructions above, and was able to get an 8TB drobo drive up.
Put ext3 on it, everything went great.

I copied about 100GB or so with no problems.

I then just did:
unmount /mnt/drobo
mount /dev/sdg1 /mnt/drobo
mount: wrong fs type, bad option, bad superblock on /dev/sdg1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

and in dmesg:
EXT3-fs error (device sdg1): ext3_check_descriptors: Block bitmap for group 256 not in group (block 0)!
usb-storage: queuecommand called
usb-storage: *** thread awakened.
usb-storage: Command WRITE_10 (10 bytes)
usb-storage: 2a 00 00 00 00 22 00 00 08 00
usb-storage: Bulk Command S 0x43425355 T 0x129f75 L 4096 F 0 Trg 0 LUN 0 CL 10
usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
usb-storage: Status code 0; transferred 31/31
usb-storage: -- transfer complete
usb-storage: Bulk command transfer result=0
usb-storage: usb_stor_bulk_transfer_sglist: xfer 4096 bytes, 1 entries
usb-storage: Status code 0; transferred 4096/4096
usb-storage: -- transfer complete
usb-storage: Bulk data transfer result 0x0
usb-storage: Attempting to get CSW...
usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
usb-storage: Status code 0; transferred 13/13
usb-storage: -- transfer complete
usb-storage: Bulk status result = 0
usb-storage: Bulk Status S 0x53425355 T 0x129f75 R 0 Stat 0x0
usb-storage: scsi cmd done, result=0x0
usb-storage: *** thread sleeping.
EXT3-fs: group descriptors corrupted!

So yah, it looks like an 8TB lunsize is not valid.
I hope the original author of this blog is reading these comments because if you never bothered to unmount and remount, then it would appear as if everything is working, when, in fact, if you ever have to unmount/remount then your data is not recoverable.

Tom, Robert, I'm glad that

Submitted by litrik on

Tom, Robert,

I'm glad that you have found my post helpful but I'm sorry to read that you're having problems.

Personally I have not seen the problems you describe. I have successfully unmounted/mounted the Drobo. No problems whatsoever.

I suggest you talk about your problem at DroboSpace or in the drobo-talk group. Maybe somebody else there has seen similar things.

drobo is suspect for ruining

Submitted by Apostolos P. on

drobo is suspect for ruining four (4) brand new disks!

Last month I was looking to buy a 4-disk JBOD to use as a portable emergency backup solution for my linux server farm. Drobo was the only readily available 4-USB-disk box at the nearby local store, so it seemed as a quick and decent solution for my needs. So I bought a drobo2 and five ST31000340AS 1TB disks.

I installed 4 of the 5 disks. After lots of effort I managed to setup an 8TB LUN containing a single 8TB parted partition. I formated that partition as ext3. I did the exact steps as Tom did above. Then I started to load drobo with data. However after having backed up 1.7TB, the front leds indicated that one of the disks had gone bad, and drobo became too slow (10-500 KiloBytes/sec read speed). I replaced with a new spare disk (after all I had bought 5 of them just for that case), and drobo seemed to start resyncing (4 orange lights) and remained painfully slow in response.

A couple of days later, drobo indicated that all disks had gone bad. I removed and checked all disks with various utilities and found out that in total 2 disks would not spinup at all (just made clicking noises continuously after powerup), 2 disks had acquired thousands of bad blocks each, and only 1 disk seemed to have survived! The items are covered by guarantee, so I hope I will eventually get new disks back.

Drobo is designed for the non-technically minded people. Documentation and utilities are intentionally made cryptic about what is going on inside it, so it is not really suitable for use by sysadms. I have no way to know what really happened inside drobo, but 4 concurrent disk failures make drobo look awfully suspect as a disk killer.

Does anyone else has any similar experience?

Apostolos

Apostolos , Hey, this is Tom

Submitted by Tom Loverro on

Apostolos ,
Hey, this is Tom from Data Robotics. That sounds unusual. It's possible that disks themselves were all bad. I've worked in storage a while and you'd be surprised how often we've seen it--sometimes the FedEx guy just drops a whole box and we receive 10 out of 12 bad disks from the factory. However, its not clear from the brief description exactly what the issue is. I am going to escalate this to our highest technical resources to check into this for you. My personal bias tells me it isn't a Drobo problem, but that's why we have to investiagte this. As a side note, Drobo wouldn't even physically be capable of causing bad sectors--no physical mechanism to do so.

Please email me at tom {at} datarobotics [dawt] com and I will make sure you're taken care of asap.

I hope someone responds

Submitted by Dan on

I hope someone responds soon... I'm going to be setting up a nearly-identical system in a few days. My only difference is I'm going to attempt to use the linux hfsplus driver, instead of ext3. Why? I want to be able to read/write to it from my Mac under certain situations. The last time I tried writing to HFS in Linux, it wouldn't write if there was a journal involved. I'm hoping the latest hfsplus CAN deal with journals...

Does anyone know if the Drobo works just as well with HFS+ with no journal?

I tested various aspects

Submitted by Aniviller on

I tested various aspects regarding this and results are:

You need a recent kernel with GUID partitions and big block devices enabled.
And even then it's not guaranteed to work. I was able to create a partition, but saw only 2TB of size
with standard core utilities and parted. I couldn't remount it. Then I set lunsize
back to 2TB and it still wouldn't mount. I suppose you need brand new installation
of your distribution for it to work properly with gpt.

I then set up a mbr partition with ext3 fs and it works. I filled it up to 30% with garbage
and then deleted it. One light went out when I put it in stand-by, the second in 1 hour and
3rd after another hour. I guess it's performing system check on predefined intervals. It
works well.

I bought 2x1TB disks for a start, I'll add 2x 1.5TB when more space will be needed.

Hi, i tried your method,

Submitted by Alessio on

Hi,
i tried your method, however it appears my linux box (fedora core 8, amd64) has issues in recognizing
the big LUN, while attaching it on USB2.

scsi 8:0:0:0: Direct-Access TRUSTED Mass Storage 2.00 PQ: 0 ANSI: 5
sd 8:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
sd 8:0:0:0: [sdd] READ CAPACITY(16) failed
sd 8:0:0:0: [sdd] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK,SUGGEST_OK
sd 8:0:0:0: [sdd] Use 0xffffffff as device size
sd 8:0:0:0: [sdd] 4294967296 512-byte hardware sectors (2199023 MB)

Can you tell me which kernel are you using?

I had a ton of problems as

Submitted by Anonymous on

I had a ton of problems as well, but figured them out. Points to note:

USB will not support disks over 2TB. It's a limitation of the protocol. Sorry.

Not all linux kernels are alike! Some distros come with kernels which support GPT partition tables by default, and SOME DO NOT. While everyone knows to check the 'extra large partitions' options, do not forget to enable support for GPT tables as well.

My experience with drobo on

Submitted by mathias on

My experience with drobo on linux is similar to Tom's (November 29th 2008) and Robert's ( November 30th, 2008).

My linux kernel is a 2.6.28-3, freshly installed, with GPT enabled (CONFIG_EFI_PARTITION set to y in the config for compiling the kernel).
I was able to get a 8TB LUN, mounting and unmounting was no problem.
But when I started getting data on the drive, the ext3 journal got corrupted after approximately 40GB of data.
Has anyone successfully tried to recover from such file corruption?
Was anyone able to run a Drobo on linux, filling up to 8TB data?

I'm writing my ext3 right

Submitted by Peter on

I'm writing my ext3 right now. Been fighting with this all day long. USB may be my last hurdle, but the very first was getting an 8TB LUN + ext3, and that has taken my entire day ( and I didn't have a day to spend ). And I wasn't going to mess w/ trying to manually install drobo-utils in Gentoo. So my solutions? Grab the nearest Macbook, hook up the Drobo, an make an HFS+ part. This will get the LUN set. Then go back into linux, kill the partitions w/ parted, and follow everything else involving parted & mke2fs in this guide.

We'll see on mounting/unmounting challenges. And this will be my first outing w/ iscsi. Still trying to figure out which way is up there.

johnny5 ~ # df -h Filesystem

Submitted by Peter on

johnny5 ~ # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md/3 292G 289G 0 100% /
udev 10M 188K 9.9M 2% /dev
shm 1005M 0 1005M 0% /dev/shm
/dev/sdc1 8.0T 22G 8.0T 1% /mnt/drobo
johnny5 ~ # mount
/dev/md/3 on / type ext3 (rw,noatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
shm on /dev/shm type tmpfs (rw,noexec,nosuid,nodev)
usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,devmode=0664,devgid=85)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
/dev/sdc1 on /mnt/drobo type ext3 (rw)
johnny5 ~ # parted /dev/sdc
GNU Parted 1.8.8
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: DROBO DroboPro (scsi)
Disk /dev/sdc: 8796GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
1 17.4kB 8796GB 8796GB ext3

This was using the "format as HFS+, then delete that w/ parted, etc." method in the post just above this. I'm sure it would work if you have a Vista machine as well ( xp's version of ntfs DOES NOT go over 2TB ), but I shave sterilize and destroy all Vista users in my presence so that wasn't an option.

I also sent an email to Drobo expressing my frustration over the experience and got a very prompt reply back.

btw, I did several remount tests ( and will continue to ), no issues whatsoever. I don't know if that's a firmware upgrade thing or what but I'm not seeing any problems. On to iscsi!!!

Cancel that. 49G's in, the

Submitted by Peter on

Cancel that. 49G's in, the drive stopped writing. dmesg reports "EXT3-fs: group descriptors corrupted!"

fsck can't fix it

# fsck -b 8193 /dev/sdc1
fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
fsck.ext3: Bad magic number in super-block while trying to open /dev/sdc1

Looks like I'm back to the drawing board. My hunch is that the firmware stepped in and tried to manipulate the filesystem. At that point since its version of ext3 doesn't support TLB it hosed the partition.

Im running some tests now

Submitted by chris w on

Im running some tests now based on the above.

Have used the gui to set LUN to 8T and run checks with the diagnostics. Some far its looking OK, Im dropping some files onto the array now to test a mount/unmount cycle or two.

One thought - has anyone checked if you still get problems using something other than ext3 - ie plain old ext2 or reiser?

Do you have more than 2 TB

Submitted by litrik on

Do you have more than 2 TB usable storage? If so, could you test to put more than 2 TB of data on it.

I currently have (only) 3 x 1 TB disks in my Drobo which gives me slightly less than 2 TB of usable storage. So I can't really test and confirm that writing more than 2 TB of data on an 8 TB LUN actually works.

well.... Ive dumped on 100G

Submitted by chris w on

well.... Ive dumped on 100G unmounted and remounted and its fine so far,now filling up to > 2TB and see if Im still as happy

kernel: [ 9730.228368] kjournald starting. Commit interval 5 seconds
kernel: [ 9730.233089] EXT3 FS on sdc1, internal journal
kernel: [ 9730.233097] EXT3-fs: mounted filesystem with ordered data mode.

well, the tests from the gui

Submitted by chrisw on

well, the tests from the gui with an 8TB lun worked fine, but after filling to about 2.5TB and then deleting, both the status LEDs and drobo utils still showed 39|% disk use. Im just reformatting now on the command line as ext2 rather than 3 to see if that makes any difference.

:((

Ugh... So i've come to this

Submitted by Alex Upton on

Ugh... So i've come to this page because of the same ext3 problems that's been plaguing everyone. I bought the drobo pro to use with Linux, but it doesn't seem like it's mature enough... After dumping some data on the device it generated some errors, remounted the FS as read only. Then after reboot:

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

Has anyone found a complete solution to usign the drobopro on Linux ? I'm using Centos 5.4 x86 with the 2.6.18-164.10.1.el5 kernel and iscsi-initiator-utils-6.2.0.871-0.10.el5.

I'm using an 8TB lun.

Any help would be greatly appreciated.

Same issue here. Formatted

Submitted by Mark Edwards on

Same issue here. Formatted fine, put abou 2TB of data on, unmounted and shutdown the drobo to reconnect and run the wires differently, won't mount again, complaining about:

mount: wrong fs type, bad option, bad superblock on /dev/sdb1

Seriously? That's it? I wouldn't call that "beta" support for Linux. That's barely alpha.

I've stubled into the same

Submitted by syd on

I've stubled into the same trouble at first.

I was trying to connect a Drobo v2 to a Synology DiskStation. The LUN-size was setup to 8TB on a Mac with HFS+ and then I did a reformat on the DiskStation. That took about 5 hours and looked fine at first. After putting some files on the unit, the 10% capacity LED came on. Which was odd because I'd only copied about 25GB, about 1% of the actual total size of the drives inside. I reconnected the Drobo to the Mac and Dashboard showed indeed about 230GB data. But as soon as I reconnected the Drobo back onto the DiskStation... filesystem error. So I booted Ubuntu 10.10 on VMware, did a diskcheck of the Drobo and indeed... wrong FS, bad superblock etc etc. Very bad indeed. So I reformatted with Ubuntu, but again after a while something went wrong again. I must note that I didn't use Drobo-Utils (0.6.1). There is a bug in this version that gives errors for every LUN-size you can enter at the commandline.

So I tried the complete reformat again, but this time I reset the LUN size on the Mac with DashBoard, and right after the Drobo does its usual reboot, I quickly switched over to Ubuntu and did the EXT3 format in there. (took about an hour). Right after formatting, I didn't do the mount, instead I shutdown the Drobo with the Drobo Utils, waited until the drives stopped spinning and then switched of the power and back on again.
The reason I did this, because every time when the Drobo got corrupted, the Mac seemed to detect a MS-DOS partition on it instead of Linux (GPT). I'm guessing that somewhere during LUN-setting and formatting, the Drobo firmware somehow is still set in MBR mode or something. So I have some hope that rebooting right after format helps.
Now I've connected the Drobo on the DiskStation again and sofar I've copied about 250GB onto the Drobo and deleted some files again. Now it seems to work correctly. Also the capacity indicator LED's changes accordingly. No filesystem corruptions yet. Even after deliberately removing a disk (testing Drobo's rebuild function)
It will take some more time to fill it up all the way beyond 2TB and see what happens.

(the drobo has firmware 1.3.7)

I tried the complete

Submitted by pneumonia symptoms on

I tried the complete reformat again, but this time I reset the LUN size on the Mac with DashBoard, and right after the Drobo does its usual reboot, I quickly switched over to Ubuntu and did the EXT3 format in there. (took about an hour). Right after formatting, I didn't do the mount, instead I shutdown the Drobo with the Drobo Utils, waited until the drives stopped spinning and then switched of the power and back on again.