drobo S with 2.1 firmware and Linux - issues, questions, best practices

[NickDawson]

Hello Drobo experts! Thank's to the admin of this group for approving my application. I've been looking forward to making this post for a few days. In prep, I had typed the following yesterday. Today, I tried the eSATA port and have an update to share at the end of this note. 

__________

I am building a new server rig and was feeling pretty good about my choices until my shiny new Drobo S arrived. Without a doubt, its a slick piece of hardware. However, the latest firmware seems to be presenting some problems with drobom in the drobo-utils package. 

My ultimate goal is to use esata for the transport. However, I first wanted to increase the LUN size to something greater than 2T. When I plug the device into my existing 11.04 server (so I can set it up and migrate my files while I await more part) it is seen as two 2tb drives. Currently I have a mix of disks in the device: 2 x 2T, 1 x 500G, 1 x 320G... so not exactly 4T in total storage. 

From here, I understand I have a few options. One is to leave the LUN size as is and use something like LVM or MHDDFS to concatenate the storage. More on that later. The other option is to increase the LUN size using the drobom commandline tool. 

According to the sourceforge page for drobo-utils, when Data Robotics updates firmware, they often change the device ID, making the scanning process challenging. That's my current issue. This Drobo S shows up as "USB 3.0 " (note the trailing spaces). I discovered that by running:

Code:

drobom -v 16 status

Again, according to the sourceforge page, I should be able to specify the device ID using the -s flag. The -s flag appears to be invalid. Any variant of the following simply returns the help text

Code:

drobom -s 'USB 3.0' status

(I've tried no quotes, double quotes, trailing spaces, etc). 

Any ideas on this first issue? Is there some kind of workaround for these new drobos and drobom with the USB 3.0 identifier? 

Now, on to best practice. Am I right to want one big LUN that I can format into ext3? Or... as some suggest... am I better off with LVM? Frankly, I don't know LVM well at all, but I've lived for 5 years with mdadm so how bad can it be  - I played around with this method last night, I created a group out of the two volumes from the drobo and then formatted the space and have copied some files. Seems ok? 

Others suggest mhddfs... a fuse filesystem which concatenates multiple directory structures into one. 

If performance is reasonably equal then my chief concern is data protection and making sure the Drobo is working the way it is intended. That is to say, with an LVM, I'm under the impression that, in my instance, I'll allocate 4T since it appears as 2 x 2T drives which is in fact more than the total amount available for storage. So what happens if I try and use more than the 3.whatever T I actually have? Since it seems I may not have access to the drobom utility, am I flying blind and risking data corruption? Conversely, if I use mhddfs how does it know which 2G "disk" to ultimately put the files on to? 

To build on that question: The drobo currently shows as /dev/sdg and /deb/sdh ... both appear as 2T drives. However, one may be 2T but the other is only, say, 1.2T...if I format those both as ext3 and then pull them into one virtual drive via mhddfs, and copy a file into that virtual drive, how does it know which one to use first? What if it tries to put 2T onto the /dev/sdh which is actually only 1.2T.... 

Or do I totally misunderstand the Drobo concept - does the device itself manage that part of the equation? If that is the case, again, how do I keep the system which thinks there is more storage than available for writing more than is actually available? 

whew! long post - really grateful for any thoughts or suggestions this group of experts may have!

____

my update:

The new server is up and running and boy does that core i7 transcode video FAST!

My transport options on the new server include eSATA and usb 3.0. I elected to plug the drobo into the eSATA port since I had a lot of data to move. Low and behold, rather than appearing as two separate drives (as it did using usb 2.0 on my other server), it appears as a single 2.19T drive. I had started an rsync process when it was local to the other machine, and had used mhddfs... to my pleasant surprise, when I mounted the now single drobo eSATA drive on my new machine, the files were intact. How cool is that? 

However, my fundamental problem remains. Without the at least occasional use of dobom I cannot really assess what's going on with the Drobo. Now I have the added question about the new firmware and eSATA: has DRI fixed the space problem on linux? Is it going to report correctly? If so, do I need to run resize2fs every time I expand the drive? I have 2 more 2T discs coming tomorrow (no one told me this thing is addictive!), so I guess I'll find out what happens. I added 2 500G drives tonight and neither dmesg nor df -h showed any change. when I tried to run resize2fs it said it was already as big as it could be. 

double whew! even longer post now. Looking forward to your sage advice! 

[David A. Desrosiers]

On Thu, May 26, 2011 at 9:35 PM, NickDawson <nickp...@gmail.com> wrote:

Now, on to best practice. Am I right to want one big LUN that I can format into ext3? Or... as some suggest... am I better off with LVM?

As long as your LUN sizes on Linux do not exceed 2TB per-LUN, you'll be fine with the Drobo. If you need larger LUN sizes, you need a different solution.

[NickDawson]

Thanks David.
I'm still pretty confused about my options and best practice... It
sounds like keeping a series of 2T luns is best, and then I can
concatanate them with mdhhfs (not my favorite idea to use a little
known fuse system, but it seems to have low risk).

Ive finished copying about 1.8 TB from the old system onto the drobo
(did it with the drobo attached locally to the old system). Today, I
also added another 2tb drive. According to the drobolator on the DRI
site, I should have 4.7T of available storage.

here's the kicker, using eSATA, it only shows up as 1 x 2.19T drive (/
dev/sdb) ... none of the other luns show up, they aren't mountable,
they don't exist.

So I tried a USB 3 connection and according to dmesg:

[ 1752.779776] type=1400 audit(1306538748.429:74): apparmor="STATUS"
operation="profile_replace" name="/usr/sbin/mysqld" pid=6674
comm="apparmor_parser"
[ 1752.781789] xhci_hcd 0000:03:00.0: Unknown completion code 192 for
reset device command.
[ 1752.781794] usb 3-4: Cannot reset HCD device state
[ 1753.051723] xhci_hcd 0000:03:00.0: Unknown completion code 192 for
reset device command.
[ 1753.051729] usb 3-4: Cannot reset HCD device state
[ 1753.321714] xhci_hcd 0000:03:00.0: Unknown completion code 192 for
reset device command.
[ 1753.321720] usb 3-4: Cannot reset HCD device state
[ 1753.591620] xhci_hcd 0000:03:00.0: Unknown completion code 192 for
reset device command.
[ 1753.591625] usb 3-4: Cannot reset HCD device state
[ 1753.592444] hub 3-0:1.0: Cannot enable port 4. Maybe the USB cable
is bad?
[ 1753.593323] hub 3-0:1.0: unable to enumerate USB device on port 4


It would appear that Drobo just isn't ready for linux - anyone have
any suggestions? I'd really like this to work and feel like I've got a
fairly sizable financial investment at this point too... Looking
forward to hearing your thoughts and suggestions!

[NickDawson]

just to clarify where I am...

With eSATA I get one single 2TB LUN (on a drobo with 5T of storage)
With USB 3.0 I get an error in demsg: hub 3-0:1.0: unable to

enumerate USB device on port 4

With regular USB I get 3 separate drives, but drobom still sees the
device ID as "USB 3.0" ... dmesg reports:
USB Mass Storage support registered.
[12008.482888] scsi 6:0:0:0: Direct-Access USB 3.0 Drobo S - Gen
2 0100 PQ: 0 ANSI: 4
[12008.483509] scsi 6:0:0:1: Direct-Access USB 3.0 Drobo S - Gen
2 0100 PQ: 0 ANSI: 4
[12008.484244] scsi 6:0:0:2: Direct-Access USB 3.0 Drobo S - Gen
2 0100 PQ: 0 ANSI: 4

drobom cannot find any drobos.

I cant stick with USB 2.0 - way to slow for my needs. I'd really like
to increase the LUN size and go back to esata.

Any tips on using drobom and forcing it to recognize the vendor ID
listed in dmesg?

[NickDawson]

of interest, using the latest version of drobom rather than the Ubuntu
multiverse version, I get the following. I'm not able to specify a
device however. It looks like there is a bug or crash?

$ sudo ./drobom --string 'USB 3.0 ' -v 63 view
examining: /dev/sda
id: (0, 0, 0, 0, 'ATA ')
rejected: vendor is ATA (not from DRI)
examining: /dev/sdb
id: (6, 0, 0, 0, 'USB 3.0 ')
found a Drobo
appending new lundevs to devices: []
examining: /dev/sdc
id: (6, 0, 0, 1, 'USB 3.0 ')
found a Drobo
appending to lundevs...
examining: /dev/sdd
id: (6, 0, 0, 2, 'USB 3.0 ')
found a Drobo
appending to lundevs...
returning list: [['/dev/sdb', '/dev/sdc', '/dev/sdd']]
trying: ['/dev/sdb', '/dev/sdc', '/dev/sdd']
__init__
getsubpage
DMIP sub_page query:0x01 pattern: >BBHBBBQ
mcb 000: 5a 00 3a 01 00 00 00 00 0f 00
4 before ioctl, sense_buffer_len= 0
5 after ioctl, result=0 status: 0 driver_status: 0 host_status: 0
sb_len_wr: 0 resid: 7
page_buffer 000: 00 06 00 00 00 00 00 00 22 c2 1f 53 08 00 45
the length is: 8
expected 8, got 15 bytes
__del__
No Drobos discovered

[NickDawson]

last update for today

I've learned a few things:

1) eSATA requires support for port multipliers and the Intel h67
chipset on the sandybridge motherboards doesnt support it
2) the particular usb 3.0 chipset on my mobo is also not currently
supported in the linux kernel

Plan B (or are we on D or E?) - ordered a new eSATA card with
multiplier support. Fingers crossed!

[Richard Shack]

I know this is old.  Does anyone have a way to get Drobom to identify drobo s.  This description is exactly what I am having.

Rich

[Peter]

I guess this is starting to be FAQ thing...

https://github.com/petersilva/drobo-utils#does-drobo-utiles-work-with-usb3-esata