I’ll answer this first as it’s a whole lot simpler. Yes, any of the “direct attach” Drobo’s would work for you, so the original USB Drobo, 2nd-gen Firewire800 Drobo, or the new Drobo S would all work. They’re just large block-storage devices and the host can do what it will with them - including format as HFS+.
If you’re on a MacBook, you’re going to use USB 2.0 or Firewire 800 to connect to such a Drobo, so I’d recommend the 2nd-gen Firewire800 Drobo. You can typically find this for ~$300 online. The newer Drobo S does provide you with an additional drive bay which is useful, but it also provides newer connectivity options that you can’t easily use on a Mac - the eSATA and USB 3.0 won’t do you any good.
[quote=“ConanButcher, post:3, topic:6016”]
However sadly I don’t fully understand some of your terminology :-)[/quote]
No problem - I’ve been doing enterprise storage for a decade or so, so don’t sweat it.
Let’s start with disks. They’re what’s called “block storage”, because when you format them, all they are is a huge long list of blocks to write data to. This is actually a bit of an abstraction layer in that it sits on top of the even larger list of simple 1’s and 0’s that make up binary storage - but it would suck to deal with that many addresses, so we group it into chunks called blocks. The block size is set when the drive is formatted - typically 512 bytes, 1K, 2K, or 4K. There’s still no filesystem, no data - just a lot of blocks of a fixed size.
Every local disk - your internal hard disk, external firewire or USB disks (including USB keys, inserted SD cards, etc) are block devices. The computer can at any point change data at the block level, so for instance you can write changes to a 2GB file without reading in the whole file, then writing it out again.
RAID systems are also typically block-level, so all the magic is done by a RAID controller with how to lay out the blocks. RAID is a perfect case of abstraction - higher layers (i.e., your computer) still see a big block device that can be formatted as needed, and the controller takes care of all of the magic. Drobo’s BeyondRAID is a little different, but it’s still a good way to think about it.
Once you have a concept of block storage as a base abstraction, you can layer another on top of it - the filesystem. That includes all manner of conventions for how to lay out the data and what you can do with it. How long can a filename be? What characters can be used? How many folders can be created? What’s the largest size of a file? How big a disk (or how many blocks) can we address? Do we have permissions? Etc. Everything that an OS needs is generally encapsulated in the filesystem, which is why every OS tends to have its own - Macs use HFS+, Windows used to use FAT32 and these days prefers NTFS, Linux typically uses EXT3.
Networked devices like the Drobo FS have an interesting problem. They have to manage the data on disk, so they’re doing all kinds of proprietary magic at the block layout level. Then they need a filesystem so they can actually store their OS and your data. Pretty much all consumer NAS devices use Linux, and so use EXT3 for the filesystem internally.
Networking is then another layer of abstraction. When you connect to the DroboFS, you’re not getting direct access to the blocks (well, not without iSCSI, but that’s not for this discussion), you’re just getting access to the files. And it’s indirect - you’re using a network protocol to ask the DroboFS to do certain things - list the files in a directory, get this file, write that file, change the name. It’s a fairly limited subset of commands, reflecting the fact that it doesn’t know what the remote device is using for a filesystem. Some things just can’t be done across this type of abstraction.
Just like filesystems, each OS has tended to create its own network protocol. Apple wanted really easy discoverability and support for their own proprietary things, so they created AFP (Apple Filing Protocol). Microsoft needed different workgroup and sharing features, and created CIFS (Common Internet File System). Unix and Linux needed robust permissions and the ability to seamlessly link network storage into their filesystems, and use NFS (Network File System). All of these work in different ways and provide different feature sets. One of the Drobo FS’s biggest jobs is translating all of the features they need onto the EXT3 filesystem that lives underneath. And that can be tricky.
For instance, when Mac users are having problems with AFP or Time Machine, what’s really likely at fault is something called “netatalkd” - that’s the software that runs on the Drobo and provides the AFP network protocol that Mac OS X uses to connect. It’s responsible for making Mac features like resource forks, custom icons, hard links, permissions, etc work on a foreign filesystem like EXT3 that doesn’t understand those concepts, or uses them in a different way. Similarly for Windows, “samba” handles the CIFS connectivity for Windows clients, so if they’re seeing a problem you’d typically look there.
Hey, what about my question?
So what does all of this have to do with iMovie? Well, as you’ve seen, using block storage or a filesystem directly has some different capabilities than a network drive like the Drobo FS. With block storage you can made edits without reading entire files, and with direct filesystem access you can store and manipulate all manner of data unique to that filesystem. One of these (or both) is why iMovie is insisting on a local HFS+ disk. Over the network, all it can work with is AFP, which just may not be fine grained enough to iMovie to do the stuff it needs to.
If you’d been lucky, iMovie would have just been requiring HFS+ because it needed something unique to it - case-preserving yet insensitive file naming, resource forks, or extensible metadata. Most of these can be emulated across AFP reasonably well. Unfortunately, it sounds more likely that it needed those and direct block access, so it can quickly edit and manipulate large files. And for that, you just have to have a local disk formatted as HFS+.
Didn’t you say something about iSCSI?
Yes. iSCSI is an interesting method of providing block storage - just like your hard disk or USB key - across the network to a device like a Drobo FS. It’s kind of cool in that you can keep all of your storage across the network and centralized, but still access it exactly like a local disk, including formatting it however you want, and typically with outstanding performance (as you’ve removed some bottlenecking layers of abstraction). Unfortunately there are a lot of reasons this isn’t included on the DroboFS and similar products. iSCSI (and this approach in general) has significant limitations that make it unsuitable for most people and most situations - most importantly, only one system at a time can connect and “own” the storage. Since the Drobo FS and most similar products are designed for multiple computers on your network to connect to the same storage, iSCSI hasn’t been a significant feature.
So - unfortunately it sounds like iMovie needs features only available from a local HFS+ drive - probably direct access to blocks instead of files, and some of the more esoteric filesystem features HFS+ offers. Unfortunately, this means sticking with your external hard drive.