New DroboPRO firmware fixes LUNS > 2 TB ?!

[Peter.A.Silva]

New firmware released day before yesterday.
A highlight in the release notes is the fix for LUNS > 2 TB
Anyone want to run some tests?

http://www.drobo.com/support/updates/firmware/Release_Notes_DroboPro_Firmware_1-1-4.pdf

It would be great if it were true!

[timb]

I have just had a data corruption on a drobopro using ntfs-3g and
firmware 1.1.3. Linux is 64bit Ubuntu with kernel 2.6.31
I initially tried hpfs on the drobopro, got data corruption with that,
so moved to ntfs-3g instead. I really *didn't* want to limit
myself to 2TB LUN's so ntfs seemed to be a better option. I pulled the
latest ntfs-3g from source and built it as the apt package seemed
a bit dated.

I have been doing large (200GB+) rsync transfers back and to the Linux
machine and either that and/or a couple of reboots for relocating
it has caused the problem.

So, the drobopro is now having it's last chance with firmware 1.1.4. I
did the 'manual installation' just using Drobo Dashboard on OS X
and yesterday ran the following (after setting 'lunsize' to 8):

sudo ./drobom -d /dev/sdb format ext3
/dev/sdb - DroboPro 00% full - ([], 0)
preparing a format script for a ext3 file system as you requested
OK, I built the script but nothing is erased yet...
You can have a look at it with: cat /tmp/fmtscript
If you are really sure, go ahead and do: sh /tmp/fmtscript
WARNING: Ready to destroy all your data. Continue? (y/n) y
ok... firing it off...
Model: DROBO DroboPro (scsi)
Disk /dev/sdb: 8796GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

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

mke2fs 1.41.9 (22-Aug-2009)
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 29 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

--- This took about 1 hour to complete. I will advise if I get any
problems using ext3 (gawd I hope not!)

Tim Burgess

Software Engineer - Coral Reef Watch
Satellite Applications and Research - NESDIS
National Oceanic and Atmospheric Administration
http://www.coralreefwatch.noaa.gov
675 Ross River Rd, Kirwan QLD Australia 4817

[Andy Lawson]

Very interested in any results you might see with this....
Please post here!

Cheers,
Andy.

[Alex]

I just received my Drobopro and I've got nothing but disappointment
from it... Using firmware 1.1.4 I've been able to create an 8TB thin
provisioned LUN and format it as ext3 over ISCSI, however upon unmount
or reboot the block size becomes corrupt. After writing a few GB of
data to the device, the ext3 file system journal becomes corrupt and
its re-mounted as read only... I've considered backing out of the >2TB
LUN idea , but given how poor the Linux support is I don't think I can
trust my data to be safe on the Drobopro under Linux...

Sadly I think i'm going to either have to use Windows and NTFS or
return the unit and purchase something else...

Here's what I've done to reach my current conclusion, perhaps I've
done something terribly wrong ?

Thanks in advance,
-Alex

Using Centos 5.4

Kernel = 2.6.18-164.10.1.el5
ISCSI = iscsi-initiator-utils-6.2.0.871-0.10.el5

# /etc/init.d/iscsi start
# iscsiadm -m discovery -t sendtargets -p 1.1.1.2
# /etc/init.d/iscsi restart

In this file - /var/lib/iscsi/nodes/iqn.2005-06.com.datarobotics
\:drobopro.tdb093040844.node0/default

Changed this:
node.session.cmds_max = 128
node.session.queue_depth = 64
node.conn[0].tcp.window_size = 524288

to this:

node.session.cmds_max = 16
node.session.queue_depth = 16
node.conn[0].tcp.window_size = 65535

iscsiadm -m node --logout
iscsiadm -m node --login

parted -s /dev/sdb mklabel gpt
parted -s /dev/sdb mkpart primary ext3 0 100%
parted -s /dev/sdb print; sleep 5
mke2fs -j -i 262144 -L Drobo01 -m 0 -O sparse_super,^resize_inode /dev/
sdb1

mount /dev/sdb1 /nas

Then shortly later:

EXT3-fs error (device sdb1): ext3_check_descriptors: Block bitmap for
group 19456 not in group (block 0)!
EXT3-fs: group descriptors corrupted!

[Elliot]

We went through the 8TB LUN bit with 1.1.3. Gave up when things started getting corrupt after a few hundred GB transfers. We went to 2TB LUNs and haven't had a hitch since (besides needing more inodes, which I'm happy to report appears to be working just fine after reformatting.) drobom even reports deletions correctly after some time.
I'm not sure what version of open-iscsi we're using but we're running on Ubuntu Hardy.

> --
> You received this message because you are subscribed to the Google Groups "drobo-talk" group.
> To post to this group, send email to drobo...@googlegroups.com.
> To unsubscribe from this group, send email to drobo-talk+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/drobo-talk?hl=en.
>
>

[Peter.A.Silva]

your configuration looks fine to me. just do tune2fs -l on the device
and verify
that the blocksize is indeed 4096... Ugh...

If you're not out of patience, try this:

http://kbase.redhat.com/faq/docs/DOC-9855

It says to do it at the lvm level, rather than using parted.
I have no idea if that works or not. Would be cool to know.

If that doesn't work you can just repeat your procedure, but use USB
or firewire.
isolate whether it is to do with firmware reading disk data or the
attachment protocol.

that kernel sounds really old... any way to get something modern like
2.6.31 on there?

[Peter.A.Silva]

oh, and the obvious one... does it work ok with 2 TiB luns?

On Jan 11, 8:31 pm, Alex <alex.up...@gmail.com> wrote:

[Alex Upton]

Thank you for your reply, I'm curious enough to test again with LVM, it's worth a shot, although I fear that Data Robotics would show me the door if the LUN became corrupt at some point... They really need to iron out a solid support model for Linux.

I was about to try a 2TB LUN, but unfortunately the drobo-utils wouldn't resize the LUN it had created nor would it destroy the existing one.

I tried:

./drobom -s DROBO set lunsize 2 /dev/sdb PleaseEraseMyData

And each time the unit would reboot, but ./drobom status or info would still show 8TB. After 3 attempts I shutdown, swapped the drive and installed Windows... :( However I am happy to report that under this setup it has been a flawless setup and the unit's performance is impressive... Just not elegant.

The only way I was able to change the LUN size after it's initial setup was through the native win32 tool.

As for the kernel, the 2.6.18 base is very old, but it's the last official release from Redhat for their enterprise build, I figured for my critical storage I'd be best using something that should be rock solid and stress tested instead of the latest... I'd personally prefer to use Gentoo, but I figure going cutting edge could be dangerous.

I currently have it under NTFS and a 4TB LUN, I figure I'll carve off another 4TB LUN and use that for EXT3 testing testing purposes.

I will certainly try the LVM setup you suggested, that is interesting and I'll also test on Gentoo / Fedora / Ubuntu to compare performance / setup issues.

Thanks again,

Alex

--
You received this message because you are subscribed to the Google Groups "drobo-talk" group.
To post to this group, send email to drobo...@googlegroups.com.
To unsubscribe from this group, send email to drobo-talk+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/drobo-talk?hl=en.

--
web: alexupton.com, therealghostbusters.com
twitter | @AlexanderUpton /
Gtalk  | alex.upton / Linkedin | alexupton

[David A. Desrosiers]

On Tue, Jan 12, 2010 at 10:28 AM, Alex Upton <alex....@gmail.com> wrote:
> Thank you for your reply, I'm curious enough to test again with LVM, it's
> worth a shot, although I fear that Data Robotics would show me the door if
> the LUN became corrupt at some point... They really need to iron out a solid
> support model for Linux.

If you're running a LUN > 2TB, they will show you the door. IME, if
you mention Linux, they start walking you towards the door anyway. :(

[Peter Silva]

For the drobo pro, you really should be using 0.6.2.  

The ui was changed in 0.6.2 because people wanted standard prompting.  You should not need the -s anymore.

what was:

./drobom -s DROBO set lunsize 2 /dev/sdb PleaseEraseMyData

should now be:

./drobom -y set lunsize 2 /dev/sdb

(y meaning answer yes to the ´really´ prompt...)

On Tue, Jan 12, 2010 at 10:28 AM, Alex Upton <alex....@gmail.com> wrote:

[Peter Silva]

oops!  the above was wrong...

./drobom -d /dev/sdb -y set lunsize 2

is correct, I don think putting the device at the end works anymore...

[Alex Upton]

Thanks, I am using 0.6.2, the latest tarball from the sourceforge site. I'll try again with the updated syntax to see if it makes a difference and report back.

From the documentation it's not clear how I would go about creating another LUN while keeping the existing lun with drobom. I'd like to be able to have a 4TB NTFS and another 4TB EXT3 LUN for ext3 testing without destroying the NTFS LUN and data each time.

Any ideas ? 

Thank you,

-Alex

[Peter Silva]

Drobom doesn't do manual lun management.

I cannot figure that out without a unit to play with.

You have to use a commercial dashboard to to create

the second lun.