Drobo

Drobo Speed Compared to Higher End Drobos

Hi Folks -

I’m a brand new (last thursday) owner of a drobo rv 2. filled with 4 2TB drives. I bought the drobo for two reasons:

My iTunes library was reaching 2TB and I wanted a long term solution instead of every few months buying a bigger drive (I’ve been doing that for a while).

I’m the owner of WBP SYSTEMS (makers of Heap CRM and Torch Project Management) and we are starting to spend some seriose amounts of cash on Amazon S3. I was looking at the drobo as a way to test if the Pro(s) might be a reasonable solution.

Anyhow, I can’t say I’m blown away by the speed. It took about 36 hours to copy a little under 2TB of data to the device. I’m sure the pro is faster, but is there this much discrepancy between claimed speeds and actually speeds on that device as well?

Two important things:

  1. Drobo does some background housekeeping/optimization after disk relayout (what happens when the disk configuration changes). This can cause performance to be degraded during initial use. It’s best to let Drobo “rest” for 48-72 hours before doing any performance testing, so the its background operations don’t skew your results.

  2. Drobo S/Elite/Pro are faster than Drobo gen2. They have faster processors (and faster interfaces). We have a Pro at work and I have gen2 at home. The Pro is definitely faster, especially over iSCSI.

thats 15mb/sec, which is a touch slow, but nt surprising if drobo is busy, i’d expect probably north of 20mb/sec, but not by much

plus dont forget if its your itunes library - i would imagine its a lot of small files - which does tend to be MUCH MUCH slower than simply copying a massive large file.[hr]
also - were you using it at all during that period - drobo , unfortunately because of the design, is particularly poor and simultaneous reading and writing - if you are reading off it, then the write speeds go south, quickly

Humm:

http://www.drobo.com/images/inside/lightbox/Performance-Charts-lg.gif

So, your (Docchris) actual performance is about 60% of the claim (I wonder if that is consistant with the claims up the line) . Interesting. No, I wasn’t doing anything else on the drobo.

I would be interested to know more about this idea of resting the drobo. That doesn’t make much sense based on how raid works (I know drobo isn’t raid , but I’m assuming that it works on the same principals of xor ing N-1 to the N). The drives were all blank and brand new, so there wasn’t any reason for it to be moving files around.

I don’t think anyone outside DRI really knows what happens, but a few possible things come to mind…

  1. Scanning drive integrity (it has been mentioned in the past that Drobo does a period scan to predict upcoming failures, rather than waiting for the failure to occur)
  2. Defragmenting (Drobo manual says not to defrag your Drobo, presumably Drobo does it for you)
  3. Optimizing data layout. For example, especially in mixed-capacity cases it’s possible to keep fault-tolerance with data in a variety of configurations (depending on extra space on drives), so there may be some optimization that happens silently to “re-balance” the FT data.

AFAIK, only Drobo-S/FS/Elite/Pro do that, NOT Drobo (which is a pity, since a firmware upgrade would easily fix that :frowning: ).

i know drobo does monitor fragmentation on its internal filesystem and defrags/optimises it

i would also not be surprised if it simply wrote the data with duplication to begin with (i.e. if you have 4 drives it writes it something along the lines of RAID 10 or 01) and then in “quieter” periods goes back and changes it to something more akin to raid 5 (i.e redundancy through partity rather than the less space efficient duplication).

but yes, i would still be most inclined to point the finger at it being lots of small files. can you time a 10GB file for us? (once drobo has been resting a while)

Hi Folks -

I first want to thank everyone for commenting.

I will test a folder of 10MB files totaling 10G when I get a chance. I need to write a test application to replicate simultaneous reads/writes from many users. Testing a single 10G file is pretty worthless if it doesn’t replicate to small files because that isn’t what the data of a web application looks like. (The files are peoples uploads)

Ok, now let me preface this by saying that I’m a software engineer, not a hardware engineer, and obviously I don’t know the details about how “BeyondRAID” differs from RAID, but it seems that in the absence of information from the company there is a set of myths developing about the Drobo’s operation, some that don’t make sense.

RAID5 is fast because if you have a set of bits, you can write some at the same time. If you have four drives, the first 3 bits will be written while a parity bit (XOR of bit on drive 1+2 then XOR of bit on drive 3) is written to the fourth drive (XOR is one of the fastest operations so shouldn’t be a constraint – the genius of this is that XOR is like addition, if you know 3 of 4 you can always find the 4th regardless of which one is missing); this pattern repeats itself across the stream. So, in terms of the mechanical process, you speed up the operation by 3. RAID 1, however, is simply a bit for bit copy from one drive to another. Meaning that you don’t loose any speed over a traditional drive (because they are written at the same time) but you also don’t gain any.

Now, there are many things wrong with RAID. It is unclear how to rebuild from vendor to vendor, it is temperamental to when you insert drives, etc. However, the concept is really good engineering. I find it really unlikely that DRI would choose to write the data in a slower fashion when this concept works so well.

All of this operates at the drive level, files and “fragmentation” are concepts that exist at the operating system level. Understand that files don’t actually exist, they are concept created by the OS. At the RAID level they are just a set of 1s and 0s. File fragmentation is the idea that parts of the file is located on different parts of the disk resulting in unnecessary seeking. The reason drobo (or any hardware RAID device) doesn’t want you to defragment is because it is meaningless. The volume that the OS mounts is an abstraction created by the RAID controller (the files aren’t located where the OS thinks they are – think about it, the OS thinks it is a single drive).

The device isn’t real likely to operate at the file level because that means that the Drobo would have to be aware of the ways certain file systems works (RAID controllers are file system agnostic because they operate below this). The fact is most modern file systems don’t need defragmenting anyway because they are more careful about how they layout the files. But who knows, maybe DRI has some special code in the dashboard on windows for Fat32 (that’s the only one that really needs defragmenting); but that doesn’t apply to me because I’m on a mac.

If drive capacities change, it is completely reasonable to believe that this would result in the Drobo moving data. It would need to go from one end of the volume to the other moving the data into onto the new drive and rebuilding the parity bit. However, that situation doesn’t apply to new drives.

So, I guess I’d ask a few questions:

  1. Is this concept of the drive being rested, is this somewhere in the KB or is this a idea that has surfaced in the forums?
  2. I’m a little surprised that I haven’t gotten a more definite response from DRI about how the PRO will perform compared to the Drobo. (I’m getting the impression they are the only ones who really know)
  3. Is there some (real – not marketing) tech specs on how beyond raid works? If I knew how it worked, I’d have a really good idea if will work in a web app environment.

i meant more test to 10gb file to find out what is slowing your drobo down[hr]
just to address your longer piece

drobo fundamentally works at the block level - blocks are redundantly protected either through parity or duplication, the fact that it can mix and match these is key to how it can work with multiple drives all of different sizes, it just need to ensure that for any given blocks of data , they can be created if lost.

i believe the drobos actually run VXworks internally - and they do have a file system which they use to write to the disks (i have no idea what that is)

but when my drobopro was having issues, i was advised by support that the drobo internally was seeing very heavy levels of fragmentation and it was attempting to optimise this (which was fair - i had been totally hammering my very very full drobo!).

so while RAID as you describe it is the theoretical basis - drobo does introduce another layer of complexity -

this is also why drobo only works with specific filesystems - because its works at the block level and redundantly protects blocks, soif it cant recognise the fileystem it ant know what is free and what is not free. (i.e what it should or should not bother protecting)

to answer your specific question

  1. im not sure if it is on their website , but support (and Jennifer - DRI’s voice here on the forums) does ask that you allow at least 24 hours before attempting to benchmark (to allow drobo to finish any internal optimisations it may be doing)

  2. DRI have pointer to performance figures on their website with what i will guess as best case scenarios for both drobo and drobopro

  3. basically no - beyond raid is proprietary - and the whole point of “how it works” is their confidential intellectual property (and is also why disaster recovery firms cant work with drobos

the issues with simultaneous read/writes was explained by a dri employee on the previous forms as:

the virtualisation layer between the blocks the OS see and the internal layout of drobe is quite obviously stored in a mapping table - which is too large to be totally loaded into drobo’s memory, so if you are reading from one place and writing to another , it involved continually loading and unloading the appropriate bits of the mapping table, which dramatically hits performance. (i assume Drobopro has much more memory, and mine seem to be less affected than the drobo was, but it is still noticeable that simultaneous operations hurt performance

While I can’t speak for HFS, NTFS can and will get fragmented, largely depending on the type of use. Files will generally get fragmented more slowly on NTFS compared to FAT32 due to the way blocks are allocated, but they still get fragmented eventually. Thus, RAID stripes still get fragmented - the performance hit just doesn’t show up as quickly, unless you’re using solid state storage. :slight_smile:

Why would a NAS(Drobo FS) have issues with simultaneous reads and writes, that feels like it is against the nature of the whole idea? Why else would you stick it on a network?

For the reasons I said… Due to the inherent design

These issues could easily be minimised by giving the device more operational memory, and also a large buffer

Well, that is scary then.

NAS isn’t always used for multi-user. Sometimes it’s just single/few users that need to have the box remote.

Case-in-point, both myself and my wife access files at home, but it’s rare for both of us to be accessing files simultaneously, and it’s much more convenient to have data stored and shareable in a central location rather than sneakernet-ing things all the time.

Router-based USB storage sharing often suffers performance problems as well, though likely for different reasons.

Well multiuser depends what you mean. You could stream video from it at the same time as you download stuff to it and stream audio as well. But since it supports network and gigabit NW that shouldn’t be an issue if it is a NAS. The bottle neck shouldn’t be the disk side of it.

True, single-user could do multi-stream.

I did some performance testing with my Dorbo v2 when it was new. I did a hard reset, reformated and performance tested at least 10 times. The performance was terrible. Then I realized that it did something after the format. I had to make all tests again but with a long resting period after each format.

And yes, the performance is bad compared to almost any other RAID solution. I do not think it is the RAID calculations that takes time. It is more likely the thin provisioning. You get the ability to mix drives and expand space as your needs grow, but you pay with performance. A Drobo v2 is not the perfect solution for every storage need.

Drobo Pro is different. You get the same features and flexibility, but you don’t suffer the same performance issues. Instead you pay more money.

Drobo isn’t a multi-user NAS. It is a home-user NAS with the single strength that it is capable of taking drives of different sizes. I have a rev 2 that I’ve relegated to backup service for my NAS (from another vendor) because the performance, even on Firewire 800 was so bad. I get several times the performance of Drobo on the other NAS in part due to a much faster CPU and more memory. Still, I don’t think it’s the thin provisioning that is Drobo’s achilles’ heel. Any other NAS will support things like SMB (Microsoft Networking), AFP (Apple) and NFS as well and have a TCP/IP stack in the middle. While it won’t appear as native to the OS it does have to handle the translations from requested system to host (EXT4 in my case). Drobo’s thin provisioning has to do the same.

In the end I think Drobo’s performance issues come down to the small CPU (seem to recall it being around a 500Mhz ARM based) and memory (not sure how much it packs). Add to that the amount of housekeeping BeyondRAID does (as Docchris points out it stores data in a mix of mirror and parity blocks and cleans those up depending on how much disk space is available, etc.) Give Drobo a faster CPU (like a 1.6Ghz Celeron) and it would probably perform better. But isn’t that what the Drobo S and FS are?

Keep in mind that Drobo’s strengths are it’s “plug and play” drive configuration made for non-technical folks. If you need speed and true multi-user access it’s not the answer. The way I’m using mine now, as a backup for my NAS (which is also a backup server) it works fine. I just couldn’t use it as frontline storage due to its lack of speed (never more than 30MB per second with a tail wind compared with around 65MB per second on the NAS).

haha, i want a drobosuperultimatepremiumelite with go faster stripes

24 drives and a Core i7 980X (hexacore!) (and presumably a dedicated hardware XOR engine)

preferably for about $499 please :slight_smile:

Docchris…no but for the price of a Drobo S with its 750Mhz ARM CPU I got a 1.6Ghz Celeron NAS beastie. :slight_smile: For the price DRI could’ve put something a little beefier in the original Drobo and rev. 2 to begin with though I’ll admit I’m not sure which CPUs VxWorks runs on. The CPU in the original and rev. 2 is the same as that in Apple’s TimeCapsule. Considering how much work Drobo has to do to map and maintain the RAID I think it’s considerably underpowered.

The Drobo FS is running a Linux kernel if I read it correctly and packs a much faster CPU. Now if it only had FW800/USB and eSATA it would kick ass. :slight_smile:

And my rev 2 does get used thanks to Drobocopy. I copy off my NAS shares to it as a backup to the backup every week.