What's The Fastest Partition Scheme On Cheap Flash Media?
What's the Catch?You read the Fastest Flash article so you already know Ext4 can turbocharge your thumb drive. But you run Linux, so of course want even more! Is there anything else to do?
Yup. Use a GPT (GUID Partition Table) rather than the usual MBR scheme. It will hop up flash performance on almost any filesystem -- not just Ext4.
Ext2 Ext3 Ext4 Reiser3 VFat NTFS Write 368 501 125 582 518 174 Read 53 60 53 72 98 118Okay, now the same disk in the same test with a sleek new GPT:
Ext2 Ext3 Ext4 Reiser3 VFat NTFS Write 346 433 113 725 512 123 Read 51 55 53 64 68 113Everything that matters kicked up a notch! Ext4 sheds some of its advantage, but still wins easily. NTFS makes dramatic headway in write, and VFat shows a strong read improvement (though almost nothing in write times.) What's up with Reiser? It's worse on write but better on read! Flash is weird, but it's entirely possible that Reiser is even weirder. Stay away.
But There Must Be A Catch, Right?So what's the downside? Almost nothing. All modern systems can read and write to GPTs so you should have no problem with simple data exchange. Gnome and KDE disk tools can initialize GPT, and if you're a command-line junkie you can use gdisk. Both Linux (GRUB or Syslinux/Extlinux) and Apple computers can boot from GPTs.
Conspicuous by its absence from that last sentence is Windows. Most versions won't boot from GPT-formatted disks. You may run into varying degrees of difficulty with other OS types as well. In general, you'll find it fairly simple to boot from a GPT on Linux or x86 Apple, but otherwise beware. For most Linux users, this should be a non-issue.
What's Going On Here?Why does changing partition tables pump up flash media performance? The honest answer is, we're not quite sure. But Ted Ts'o, a lead designer and maintainer of the Ext4 filesystem, has a hunch that it comes down to the erase blocks.
Flash memory doesn't work quite like a spinning disk drive. Before it can write to a cell, it must first erase it. Usually, this erase operation happens in blocks of 128 KB (this large block limitation does not apply to reading or writing, just erasing). To make things a bit worse, the block erase is fairly slow.
This raises a nasty issue: what happens if the partition table doesn't align the filesystem blocks with the erase blocks? Sometimes it will be necessary to erase and rewrite the same block twice when an operation straddles the erase boundaries. Ouch!