Why We Format Delivery Drives in ext2, Not exFAT

Every delivery drive that leaves the building gets formatted ext2. Not NTFS, not HFS+, and never exFAT — no matter how convenient exFAT is for moving a DCP off an editor's Mac in the first place. This isn't habit. It's a requirement the projection booth enforces whether we like it or not, and it sits one level underneath the broader vetting question we've written about in our own DCP-house checklist. This note is the narrow technical decision that checklist doesn't have room for: what the server actually reads off the drive, and the one formatting detail that trips people up even after they already know to reach for ext2.

What the Cinema Server Actually Reads

A digital cinema server isn't a general-purpose computer running whatever OS the vendor felt like shipping. It's a Linux appliance, and that's the entire reason this conversation exists. The ISDCF specification that governs physical DCP delivery is explicit about it: there must be exactly one MBR partition and an ext2 or ext3 filesystem — no more partitions, no less, and no substituting a filesystem the server was never built to mount.

That's why exFAT and HFS+, macOS's native format, are non-starters at every venue we've dealt with. It isn't a compatibility hiccup a firmware update might fix someday. D-Cinema servers are typically Linux-based and are required to have read support for ext2 or ext3 specifically, and a drive formatted outside that pair just doesn't show up as a mountable volume in the projection booth. The physical side follows the same logic: the CRU DX115, the docking-sled drive most houses standardize on, exists because it slots directly into the server's own bay instead of relying on a USB bridge that adds one more point of failure.

The Inode-Size Detail Most Formatting Tools Get Wrong

Knowing to format ext2 gets you most of the way there. Not all of it. The inode size has to be set manually to 128 bytes, and most formatting utilities default to 256 — nothing in a typical formatting dialog flags that as a problem. Get it wrong and the failure mode is worse than an outright rejection: the server may refuse to mount the volume at all, or it may mount it and then choke partway through the read, which is a far more stressful thing to discover during a festival's load-in window than at the edit bay two weeks earlier.

There's a reason ext2 was the sensible starting point to begin with. Ext2 skips journaling entirely, which means fewer writes to disk for the same operations — a property that matters less for playback than it did for the flash and solid-state media the format was originally optimized for. It's also why some houses skip ext3's journal on a DCP drive on purpose: the volume gets written once, read once by the server, then wiped and reused, so a journal is solving a durability problem this workflow doesn't really have.

Where NTFS Still Shows Up, and Why We Don't Reach for It

Some venues will still take an NTFS drive, and FAT32 shows up occasionally too, though its 4GB per-file ceiling rules it out for anything feature-length. We default to ext2 anyway rather than gambling on which fallback a given projectionist's server happens to tolerate that week — the same instinct behind another drive-level decision we've written about, where we'd rather commit to the format the server actually wants than hedge across three it might accept.

Format the drive the way the server needs it read, not the way our own machines default to. It's a small decision, and it's exactly the kind that sits underneath every festival cut we send out the door — right alongside the sound mix and the color grade, just further from the screen.