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:
- 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?
- 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)
- 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.