Ideal linux usage with 4 2T drives

[Ranjan Bagchi]

Hi --

So some notes with a Droboshare setup, 4 2T drives connected
[initially via ethernet, then USB] to a Linux box. I'm backing up a
lot of big files -- 2G+. Some in the 40-50G range.

I formatted it as an 8T ext3 volume (while attached via USB) -- just
using fdisk and ext3.mkfs. df shows [still] 8T available.

I loaded rsync on the Droboshare, and started rsync'ing.

It seemed to have real issues with the really big files, especially on
restart. ssh'ing in, the filesystem was very strange, I'm assuming
the filesizes were too big, since I was seeing negative sizes, and a
lot of utilities, including md5sum didn't work.

Hooking it up by USB seemed to work better. Rsync behaved much better/
faster while directly attached.
However, it's currently showing a red light on drive 1 (volume full?)
having used < 5T.

So, how can I use this best? If available storage is in the 5T range
[which kind of makes sense with redundancy], is there a way of
convincing linux that it's in fact a 5T volume and to give a device
full exception?

Thanks!

Ranjan


$ df -h /dev/sda1
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 8.0T 4.9T 3.1T 62% /mnt/drobo

drobom output:
$ drobom info
---------------------------------------------------------
Info about Drobo Name: Drobo disk pack Devices: /dev/sda
---------------------------------------------------------
query config result:
(4, 16, 8796093021696)
max lun size is: 8796093021696

query capacity result:
(32016285696, 5950485970944, 5982502256640, 0)
Physical space... used: 5950485970944 free: 32016285696 Total:
5982502256640

query protocol version result:
(0, 11)

query settings result:
(1259922381, 8, 'Drobo disk pack')
Drobo time is Fri Dec 4 02:26:21 2009

query slotinfo result: number of slots: 4
[(0, 2000398934016, 0, 'red', 'WDC WD20EADS-00S2B0', 'WDC
WD20EADS-00S'), (1, 2000398934016, 0, 'green', 'ST32000542AS',
'ST32000542AS'), (2, 2000398934016, 0, 'green', 'WDC WD20EADS-00S2B0',
'WDC WD20EADS-00S'), (3, 2000398934016, 0, 'green', 'ST32000542AS',
'ST32000542AS')]
query firmware result:
(1, 252, 21110, 14, 6, 'Aug 31 2009,18:12:03', 'ArmMarvell', '1.3.5',
['NO_AUTO_REBOOT', 'NO_FAT32_FORMAT', 'USED_CAPACITY_FROM_HOST',
'DISKPACKSTATUS', 'ENCRYPT_NOHEADER', 'CMD_STATUS_QUERIABLE',
'VARIABLE_LUN_SIZE_1_16', 'PARTITION_LUN_GPT_MBR',
'FAT32_FORMAT_VOLNAME', 'SUPPORTS_DROBOSHARE',
'SUPPORTS_NEW_LUNINFO2', 'feature x0800', 'feature x2000 '])
drobo says firmware revision: 1 . 252 ( 21110 ) was built: Aug 31
2009,18:12:03

query status result:
(['Red alert'], 0)

query options result:
(1, 0, 0)

query luninfo result:
(0, 8796093022208, 5950485970944, 'GPT', ['EXT3'])

[Peter Silva]

um... I would dearly love to be proven wrong, but every time

I have tested LUNSIZE > 2 TiB on my USB only drobo, the

drobo has gotten very confused pretty quickly.  Just fill it up, oh

60% (of physical space) then remove half the data, and see what the blue lights do.   If they follow (might take a while, not sure how long, but minutes is normal, hours might be normal too.)

the space usage, then you should be fine.

The blue lights never follow for me, unless the volume is < 2 TiB.

--

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.

[Malcolm J. Currie]

I have a second-generation Drobo containing two 1TB and a 500GB SATA
drives formatted ext3 that I use to make backups with rdiff-backup under
OpenSuSE 11.1. The Drobo is connected via USB 2.0. While it was working
capacity was 48% used thus showed five blue usage lights, and three
green lights for the drives.

In the main the Drobo worked although it always was a pain to
reconnect it after a reboot or a power cut, sometimes taking a long
while to return to the expected lamp illuminations. For some time it
hasn't registered with the operating system if I remove and insert the
USB connector. Being via USB the drive isn't fixed so can't be added
to the /etc/fstab. I've noticed the same issue with memory sticks
after system upgrades until after the reboot so that might be
OS-dependent.

After a power cut while the drive was not mounted, the Drobo is
showing all the blue lamps and all four vertical drive lights are red.
What does this combination mean? Also inside the power-mode lamp is
red. The drive does not feel particularly warm let alone hot, and
again today I switched off the drive to let it settle and cool, but
this red light and the others come on immediately. There are no tests
obviously going on.

Is the Drobo dead? Or is there some recovery process?

Do I need some firmware upgrade after a incremental upgrades to the
operating system? It stopped working after some OS upgrade that
demanded a reboot. I'm using 64-bit OpenSuSE 11.1 with kernel
2.6.27.39-0.2-default.

What it the correct procedure to shut down a Drobo on Linux? The Data
Robotics help page discusses Windows and Mac. I thought it was safe
if the drive was not mounted, hence no ongoing data transfer.

Thanks for any help answering my questions. It's worrying that I
can't access old backups and perform new ones.

Malcolm Currie

[Peter Silva]

On Sun, Dec 6, 2009 at 7:43 PM, Malcolm J. Currie <m...@star.rl.ac.uk> wrote:

I have a second-generation Drobo containing two 1TB and a 500GB SATA
drives formatted ext3 that I use to make backups with rdiff-backup under
OpenSuSE 11.1.  The Drobo is connected via USB 2.0.  While it was working
capacity was 48% used thus showed five blue usage lights, and three
green lights for the drives.

In the main the Drobo worked although it always was a pain to
reconnect it after a reboot or a power cut, sometimes taking a long
while to return to the expected lamp illuminations.  For some time it
hasn't registered with the operating system if I remove and insert the
USB connector.  Being via USB the drive isn't fixed so can't be added
to the /etc/fstab.  I've noticed the same issue with memory sticks
after system upgrades until after the reboot so that might be
OS-dependent.

fwiw: on Ubuntu, you can use UUID's for this case to put it in /etc/fstab.  Try this and see if it works...

ls -al /dev/disk/by-uuid

Each UUID file is a symbolic link to a real device file.

determine which one corresponds to the Drobo's device file,

then create an fstab entry.  Here's mine:

UUID=f0652879-e918-4c83-a144-11bab7054573       /drobo10      ext3 defaults 0       2

yes, it will work with any USB drive as well.

 

After a power cut while the drive was not mounted, the Drobo is
showing all the blue lamps and all four vertical drive lights are red.
What does this combination mean?  Also inside the power-mode lamp is
red.  The drive does not feel particularly warm let alone hot, and
again today I switched off the drive to let it settle and cool, but
this red light and the others come on immediately.  There are no tests
obviously going on.

Is the Drobo dead?  Or is there some recovery process?

Do I need some firmware upgrade after a incremental upgrades to the
operating system?  It stopped working after some OS upgrade that
demanded a reboot.  I'm using 64-bit OpenSuSE 11.1 with kernel
2.6.27.39-0.2-default.

 http://support.datarobotics.com/app/answers/detail/a_id/102

Did you try this?

[Malcolm J. Currie]

> ls -al /dev/disk/by-uuid
> Each UUID file is a symbolic link to a real device file.
> determine which one corresponds to the Drobo's device file,
> then create an fstab entry. Here's mine:
>
> UUID=f0652879-e918-4c83-a144-11bab7054573 /drobo10 ext3 defaults 0
> 2
>
> yes, it will work with any USB drive as well.

That's a useful tip. Yes I'll try that, even if it only works for my
Ubuntu laptop that has its own external HD for backups.

> http://support.datarobotics.com/app/answers/detail/a_id/102
>
> Did you try this?

Yes, as far as I can without using Drobo Dashboard, and drobom doesn't
work for me unless I have a Drobo booted and running properly. The
reboot procedure begins with these lights showing, but they normally
disappear after about 15 seconds. Whatever I try, I cannot make any
other combination of lights to appear. All I see now are the ten blues,
four reds and the red power light. So it appears that the boot fails.

Malcolm Currie

[Peter.A.Silva]

if you know which device it will show up as, you can try skipping a
bit of device detection via:

drobom --device=/dev/sdX status

and see if that works. If it does not, then please supply output of:

drobom -v 29 status

That will give me an idea of what is causing it not to work.

Linux dashboard just does a couple of queries to make sure that it is
really talking to a drobo and
initialize some things... perhaps need to short circuit some of that
to get it to work in this case.
Did you install from source, or is it a package?

worst case, I suppose you can connect to a non-linux system to
complete the procedure.

[Peter.A.Silva]

just in case it isn't obvious: the end of that procedure is to open a
call with DRI.
You should definitely do that, best bet is a hardware issue of some
kind.

[Malcolm J. Currie]

> if you know which device it will show up as, you can try skipping a
> bit of device detection via:
>
> drobom --device=/dev/sdX status

OK, that's something to try if I can make the computer see the drive
again. Since the Drobo won't boot X is unknown.

> and see if that works. If it does not, then please supply output of:
>
> drobom -v 29 status

Traceback (most recent call last):
File "/usr/local/bin/drobom", line 5, in <module>
import Drobo
ImportError: No module named Drobo

> That will give me an idea of what is causing it not to work.

Thanks. My gut feeling is that there's some hardware fault and I need
assistance from the manufacturers.

> Did you install from source, or is it a package?

I built drobom from source, Version 0_5_0.

> worst case, I suppose you can connect to a non-linux system to
> complete the procedure.

There may be a Solaris system, but no Mac OSX or Windows.

Thanks for your help.

Malcolm Currie

[Peter Silva]

On Wed, Dec 9, 2009 at 11:01 AM, Malcolm J. Currie <m...@star.rl.ac.uk> wrote:

> if you know which device it will show up as, you can try skipping a
> bit of device detection via:
>
> drobom --device=/dev/sdX status

OK, that's something to try if I can make the computer see the drive
again.  Since the Drobo won't boot X is unknown.

did you check dmesg to see if something shows up?

 

> and see if that works.  If it does not, then please supply output of:
>
> drobom -v 29 status

Traceback (most recent call last):
  File "/usr/local/bin/drobom", line 5, in <module>
    import Drobo
ImportError: No module named Drobo

OK, there is something wrong with the installation.

Drobo.py and a bunch of other modules are supposed to be installed in systemish places where python will find them.

later versions can work without installing (looking in cwd.)

 

> That will give me an idea of what is causing it not to work.

Thanks.  My gut feeling is that there's some hardware fault and I need
assistance from the manufacturers.

> Did you install from source, or is it a package?

I built drobom from source, Version 0_5_0.

That's a year old... hmm... might want to trying something >= 0.6.0

That way it doesn't need to install anything in systemish places.

 

[Malcolm J. Currie]

> did you check dmesg to see if something shows up?

Of course. Nothing shows when the USB is inserted into the computer.
It's been like that for a while. The device just isn't seen by the
operating system.

> OK, there is something wrong with the installation.
> Drobo.py and a bunch of other modules are supposed to be installed in
> systemish places where python will find them.

Isn't /usr/local/bin systemish? drobom used to work when the Drobo
itself was working.

> That's a year old... hmm... might want to trying something >= 0.6.0

Well I've had the box since March/April time, but only had it
operational since June.

> That way it doesn't need to install anything in systemish places.

That's progress. drobom isn't a concern at present. It's the Drobo
itself that's non-functional.

Malcolm Currie

[Litrik]

On Dec 7, 4:09 pm, "Malcolm J. Currie" <m...@star.rl.ac.uk> wrote:
> >http://support.datarobotics.com/app/answers/detail/a_id/102
>
> > Did you try this?
>
> Yes, as far as I can without using Drobo Dashboard, and drobom doesn't
> work for me unless I have a Drobo booted and running properly.  The
> reboot procedure begins with these lights showing, but they normally
> disappear after about 15 seconds.  Whatever I try, I cannot make any
> other combination of lights to appear.  All I see now are the ten blues,
> four reds and the red power light.  So it appears that the boot fails.

When all lights stay on (or they keep flashing) you should check out
http://support.datarobotics.com/app/answers/detail/a_id/90/kw/flashing/r_id/100004
My Drobo started doing this earlier this morning, I contacted Drobo
Support and they told me they would be sending me a new power supply.

Litrik De Roy

[Darryl]

On Dec 6, 6:09 pm, Peter Silva <informa...@gmail.com> wrote:

> fwiw: on Ubuntu, you can use UUID's for this case to put it in /etc/fstab.
> Try this and see if it works...

Going back to the original topic: I can confirm that UUIDs work just
fine with the drobo (1st-gen), connected via USB. The drobo is
connected to a small, atom-based PC running (old) Ubuntu 8.10. When
rebooted, the drobo is automatically recognized and mounted.

[Malcolm J. Currie]

DRI are sending me a replacement drive.

Their support person first suggested I take out the drives, power
up then press the small recessed button above and to the right of the
power lead in the stadium shaped hole with a logo that looks like a
padlock. This button isn't described in the User Guide. This step
made no difference. He was expecting that only one drive light would
appear too, but all were on as before.

> I can confirm that UUIDs work just fine with the drobo (1st-gen),

> connected via USB. [snip]

> When rebooted, the drobo is automatically recognized and mounted.

That's good to know. Thanks for the confirmation. I'll look forward to
trying that once the replacement Drobo has filled bays and is mounted.

Malcolm Currie

[Litrik]

On Dec 17, 1:23 pm, Litrik <lit...@gmail.com> wrote:
>
> When all lights stay on (or they keep flashing) you should check outhttp://support.datarobotics.com/app/answers/detail/a_id/90/kw/flashin...

> My Drobo started doing this earlier this morning, I contacted Drobo
> Support and they told me they would be sending me a new power supply.

In the meantime I have received a new power supply (an 90W version
instead of the original 80W that came with my Drobo) and my Drobo is
up and running again.
All data was still intact.

Excellent support by Data Robotics.

Litrik De Roy

[Malcolm J. Currie]

Bottom line to my original question: the Drobo is faulty.

After failing to contact DRI via their website form---it just hangs
after sending---I tried their UK support line. Once I'd convinced the
support person that it was not booting, he arranged to send a
replacement and for me to return the faulty unit. I replaced the
original drives in their former locations within the Drobo, the Drobo
booted, and I can see all my files. Phew!

I also downloaded a recent drobo-utils 0.6.2.1 and drobom seems to work
if I run it in situ as root. Installing in a system location Version
0.5.0 was not finding the Drobo import. So I guess I need to set up a
PYTHONPATH.

>> fwiw: on Ubuntu, you can use UUID's for this case to put it in /etc/fstab.
>> Try this and see if it works...
>
> Going back to the original topic: I can confirm that UUIDs work just
> fine with the drobo (1st-gen), connected via USB. The drobo is
> connected to a small, atom-based PC running (old) Ubuntu 8.10. When
> rebooted, the drobo is automatically recognized and mounted.

Good. I updated /etc/fstab with the UUID, but I have not needed to
reboot yet.

Malcolm Currie

[Peter.A.Silva]

to install from a source download, the procedure is:

python setup.py install

don't just copy drobom to some random directory, will not work.

[Malcolm J. Currie]

> to install from a source download, the procedure is:
>
> python setup.py install

Although it was several months ago, I recall using this command
previously to install drobom.

> don't just copy drobom to some random directory, will not work.

I didn't. I only use build procedures, such as make, to install,
unless one is not provided or instructed otherwise in the README.

Malcolm Currie

[Peter.A.Silva]

hmm...

python setup.py install

should have worked properly anywhere... otoh, I just noticed an easy
thing
to do that will not do ¨the right thing¨. There is a Makefile
provided with the package,
but I think the destinations in the install target are wrong... hard-
coded for use by the debian packaging, doesn´t query the installed
python for setup info...

if you did ¨make install¨ it might cause what you see.

mechanisms. That could easily