summary of Thread:
– one guy claims it works.
– another guy says it ought to…
– I claim it doesn’t and indicate how to make it fail (but I only have a v1 Drobo)
– someone reproduces all the behaviors on a DroboPro with the latest firmware.
– He then tried HFS and NTFS, and found the same limitations.
– Someone claims that 16 TiB LUNS work just fine… but it turns out he’s on a Mac…
I’d say it’s pretty definitive that the 2 TiB firmware limitation for ext3 is real. I have talked with DRI about it in the past, they did not really understand that the problem existed. I think with multiple people able to reproduce problems, they should be more aware of it now.
I’m the guy that reproduced the bug with ext3 on an 8TB volume size, when testing on a Drobopro with V1.1.1 firmware.
I’m hoping this has been corrected in the V1.1.3 release, but I want to know the design limit of the volume size - I can’t find or report bugs with large volumes if I am limited to the (known working) 2TB volume size, also that gives me no advantage over my existing Drobo and I may as well send the 'pro back.
I hope my previous bug report details and logs were of use and the new firmware has some fixes!
(There is a definite hard limit at 2TB if using Firewire with Linux, but that is strictly an addressing limit in the present Linux OS firewire driver and not to do with the Drobo end. USB does not have this limitation.)
Just to update this - apparently with Linux kernel 2.6.31, recently out, the 2TB limit on firewire is gone. I haven’t tested it yet, but it’s on my list.
Also, based on my experience so far with SuSE and DroboPro, I’m not convinced the issues going over 2TB with ext3 are the DroboPro’s fault. They may actually be out-of-date ext3 tools or partition handling tools in the linux distro. I’m preparing to re-try with Gentoo and all the latest tools. I’ll let you know how it goes.
I don’t know whose fault it is, but I have just repeated the testing
on Ubuntu 9.10 with kernel 2.6.31, and all I do is fill it, oh 60% up, then
rm -rf the whole lot. Rather than the blue lights going out, they gradually fill up over a few days, and eventually the Drobo asks for another drive.
This was after a fresh reset. I dumped diagnostics, which can be sent.
Here’s a look at some parameters:
root@pepino:~/drobo/drobo-utils# tune2fs -l /dev/sdf1
tune2fs 1.41.9 (22-Aug-2009)
Filesystem volume name: Drobo01
Last mounted on:
Filesystem UUID: 03f14325-530f-4d99-9080-4fd70f8e94dc
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype needs_recovery sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 33554432
Block count: 2147483639
Reserved block count: 0
Free blocks: 1984339288
Free inodes: 33554389
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 512
Inode blocks per group: 32
Filesystem created: Tue Oct 20 08:43:33 2009
Last mount time: Sun Nov 1 21:47:24 2009
Last write time: Sun Nov 1 21:47:24 2009
Mount count: 1
Maximum mount count: 27
Last checked: Tue Oct 20 08:43:33 2009
Check interval: 15552000 (6 months)
Next check after: Sun Apr 18 08:43:33 2010
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: da5040f5-351c-467f-a151-a3428322112c
Journal backup: inode blocks
root@pepino:~/drobo/drobo-utils# drobom info slots