Drobo

Speed measurements

I have finally done all tests with the settings I found interesting. This test is only measuring write speed because I don’t anticipate large differences in read speed. Unfortunately I don’t have enough drives to have more then 2 drives mounted when testing.

Test setup
Drobo V2
2 Hard Drives: WD 1.5TB Green 5400 RPM
USB connection
16TB NTFS partition
Windows 2003

Test procedure

  • Format drive from the command line to have control over all settings.
  • Set Optimization options and Indexing option.
  • MFT padding to 8 million files if applicable.
  • Wait about 24 hours.
  • Copy lots of small files to the Drobo. (The files are between a few k up to about 5MB and the average is about 2MB.)
  • The amount of files copied was measured after about 10 hours. (About 500GB)
    Note: It is very important to let the Drobo rest after format, and probably after writing large amounts of data. I did not even reach half the speed when I started writing directly after format.

The columns

  1. Cluster size. (Also called allocation unit)
  2. Optimize for performance. (The alternative is Optimize for quick removal.)
  3. MFT padding. This is something Diskeeper can do to prevent MFT fragmentation.
  4. Allow indexing. (Windows is indexing files to speed up searches. I have never noticed any difference in search speed.)
  5. Write speed in MB/s

Conclusions
I previously thought that the cluster size would be important but it turned out to be totally irrelevant. The only setting that matter is the MFT padding, and it is only 6% difference. The other differences are within measurement errors.

Speculation
The importance of MFT padding increases with the number of files, and can probably prove noticeable when the Drobo is getting older and more files are stored. Those tests used about 500GB of data and if the performance penalty is linear, we could have a 40% difference at 4TB data. However, this only speculation.

MFT padding
Master File Table is explained here: http://www.ntfs.com/ntfs-mft.htm
MFT is stored at the drive almost like a normal file and can be fragmented just like a file. MFT padding is a way of creating a continuous space for the MFT and prevent files from occupying it. This must (in Drobos case) be done before a significant number of files are stored.
The MFT is not defragmented by the built-in defragmenter in Windows, so it is unlikely that Drobo can do it.

Padding is cool I guess. I just like how it protects my data.