Some time ago, I came across an intriguing device online, called Drobo. I watched the demonstration video and was immediately impressed. Basically the device is an external, 4-bay SATA enclosure that internally uses a RAID-like mechanism that allows you to hot-swap drives in and out while also allowing you to mix drive sizes and brands. I found this very attractive as it gives you the security of RAID without the usual hassle. Since I was working on small servers with backup-facilities at the time, I was interested in using Drobo to deliver a large and flexible pool of storage. And, as my servers run, Debian Linux in text-mode only, I was interested to see whether I could make Drobo work that way.
Linux is not supported officially by the producer of Drobo, Data Robotics Inc. They did however add support for the ext3 filesystem, though this is still in beta. Luckily, an excellent management interface for linux called Drobo-Utils was developed by Peter Silva. It features both a commandline interface as well as a GUI, though I have only used the former.
The design-choices made for Drobo do raise some issues, however. Firstly, the current 4-bay Drobo models are connected through USB2 or Firewire. This limits the possible throughput speed in such a way that any of the usual gains from striping in RAID are probably irrelevant. The peak sequential throughput rates using Firewire800 that are published on their website (52 MB/s read and 34 MB/s write) are beaten by most modern single 3.5″ SATA drives. So Drobo is useful for secure bulk storage, not for high-performance. Secondly, to avoid the user having to grow or shrink their filesystem when the drives in Drobo are changed, it uses thin-provisioning to present more diskspace to the OS than is (initially) available. This defaults to 2TB, which is also the maximum most stock linux kernels will support. If more than 2TB of usable diskspace is put into Drobo, it will present the OS with a second volume. Because this sort-of defeats the idea of ‘one big pool of storage’, I spent a lot of time looking for a way around this. As it turns out, Drobo does have a method to increase the size of the logical units (LUNs) that it presents to the OS. Drobo-Utils also supports this through the ‘setlunsize’ command. However, it is somewhat uncharted ground. After a lot of Googling, I found the proper kernel configuration settings to make linux support these larger LUN-sizes:
File Systems
Partition Types
[*] Advanced partition selection
[*] EFI GUID Partition support (NEW)
Enable the block layer
[*] Support for Large Block Devices
After compiling such a kernel, it is possible to connect a Drobo with larger LUN-sizes. Because ext3 with the default of 4kB block-size doesn’t support more than 8TB, I settled on this LUN-size value. Following the instructions in the Drobo-Utils README, I was able to partition Drobo to a virtual 8TB and create an ext3 filesystem on it. Initial tests with copying and removing a few tens of gigabytes worked very well. Due to reports about the capacity lights not turning off after removing the data, I filled it up to 15%, at which point the second of the ten capacity lights came on (so they actually indicate 5-15-25% etc). After removing this data, the lights went off over the course of about half an hour. So, I figured reclaiming free space was functional, though at a delay.
Unfortunately, after testing Drobo in the actual production environment, where it is filled up to 60-70% of its effective capacity and large amounts of data are added and deleted daily, it turns out that the device does lose track of the available free space on the volume. It regularly happens that I delete 50-60 GB and Drobo shows no drop in used space, not even 12 hours later. Reported space usage now hovers between 82% and 87%, giving a yellow alert whenever at 85% or more. It appears the situation is stable like this, but I don’t really trust it very much. It seems the only solution is to go back to a 2TB LUN-size. That’s being reported as fully functional. Apparently the beta support for ext3 fails at these large volume sizes.
My alternative idea to solve the multiple volume issue was to use LVM to bring multiple Drobo LUNs together in a single logical volume. However, because LVM uses a different disk layout than ext3, support for this would need to be added to Drobo’s firmware. Since Data Robotics explicitly states that LVM is not supported, there is little reason to expect that that will happen anytime soon.
Concluding, I’d say that Drobo is great for flexible bulk storage for your desktop or laptop computer. Its form-factor and connectivity support this notion. Maybe it was my mistake, trying to coerce Drobo into providing high-performance, highly-reliable storage for servers. It’s just not very well suited for that task. Coincidentically, as I was struggling with Drobo on linux, I learned quite a lot about software RAID and LVM2. This make me realise it’s quite well possible to create a very flexible and secure storage setup using those, with little more than a case with hotswap SATA-bays and my favourite linux distro. So there will be more about this soon!