PLUS - if you have just set it up - it often needs 24-28 hours to finish its housekeeping tasks - it should get a little bit faster
PLUS - itunes library is presumably a LOT of relatively small files - and almost all storage systems suck at that - compared to a handful of very large files, so im not surprised the performance isnt as good as if you were copying over individual large files.
Once I get through the initial setup and transfer, I think ~20MB/sec will be plenty of speed for what it being used for. (iTunes local and streamed to AppleTV’s and Time Machine)
Just wanted to make sure I wasn’t missing some ‘low hanging fruit’ performance-wise.
On another, kinda related note…
VMWare makes me nuts because every time you use the virtual machine, it makes Time Machine think the whole file has changed and I wind up backing up the .vmdk file multiple times per day. Besides excluding it completely from the backup any tips on that?
What do you do in your VM? I don’t do anything in mine that I keep in the VM, it’s always either in a folder shared from the Mac side, or on a network drive. I have just on backup of my “golden VM” image, which I just update if I install some big program or other, and I exclude the actual “working” VM from Tome Machine altogether.
I don’t use a Mac, but VM virtual disks have a “Nonpersistent” setting which causes it to discard changes when you power down. if you are only using your VM for IE then you could consider using this option to discard any runtime data generated by using your VM and it might help.
I’ll have to check my packaging to see if there’s already a note, but if not, there should be a final step that says “Let Drobo get comfortable in its new home. Performance will increase over a 24-72 hour period as Drobo optimizes itself.”
It’s a lot like the break-in period for thermal compound.
Essentially, yes. It’s not supported except for the case they describe. Other uses and other tools can and will confuse Drobo.
Even though Drobo (except for DroboShare and Drobo S) doesn’t handle the maintenance of the filesystem (the OS does), it still needs to be aware of the filesystem usage, and because of that, it needs to know how to access the filesystem.
Think of it like taking your car to the mechanic.
If your car is all OEM parts, no problem.
If you have some kind of special part, the mechanic may not be familiar with it, and repairing it or related systems may be difficult. In other words, Drobo/DRI/Dashboard doesn’t know what you’ve done with Disk Utility or other drive-manipulating software.
However, if that same mechanic installed that special part, then (s)he is familiar with it, and repair of it or related systems is fine. This is the case for using Disk Utility as DRI describes. Drobo/DRI/Dashboard is aware of it and understands it.