0

I have a brand new flash drive, plugged into a Raspberry Pi. I want to write stuff to the drive and then easily read it on macOS, Windows, or other linux distros.

How should I format this drive, using cli tools, to be one big file system that every system can easily use?

We can ignore issues with making sure data is all written to the drive / clean unmounting for now, but it might be nice to touch on this. Bonus points for an answer that is resilient to hot unplugging.


While I've successfully used drives without a partition table on linux only drives in the past, I understand that a partition table is useful for ease of use on other operating systems.

Should standard BIOS partitions/MBR (fdisk/cfdisk) be used? Or do we want to format with GPT?

I'm presuming making one "primary" partition the maximum size with fdisk is the standard approach, however what "Partition type" should be used? Not the default 83 surely?

As for filesystem, is FAT32 (mkfs.fat [right?]), VFAT (mkfs.vfat), or something else the "standard"? Microsoft is pushing exFAT(mkfs.exfat) for larger drives (my drive is 128GB) now, right? However, I hear exFAT is not supported by the kernel on some linux distros (in my case Raspbian). It would be nice to not need to use FUSE to mount, which I understand is for exFAT.

1

I have a brand new flash drive

Most likely it is already formatted in a standard way (FAT32 for small drives, exFAT for large ones).

While internal disks usually come completely blank (due to a large variety of partition layouts), removable media are sold as usable out-of-the-box since practically everybody wants a single giant partition anyway.

Should standard BIOS partitions/MBR (fdisk/cfdisk) be used? Or do we want to format with GPT?

Small removable media traditionally use MBR, or sometimes even no partitioning at all (aka "superfloppy" mode – always the case for floppy disks, but used to be common for USB sticks too).

Many general-purpose operating systems will recognize GPT on USB sticks without any problems (Windows Vista and later have GPT support on x86), but many embedded devices (TVs, game consoles, etc.) will not, so MBR is still the usual choice.

Note that Linux fdisk does support GPT as of 2010, although it took a few more years for this support to reach Debian.

I'm presuming making one "primary" partition the maximum size with fdisk is the standard approach, however what "Partition type" should be used? Not the default 83 surely?

Stick to the usual Windows partition types, such as 0c for FAT32 and 07 for exFAT or NTFS.

If in doubt, format it on Windows and just check what the resulting partition table looks like.

As for filesystem, is FAT32 (mkfs.fat [right?]), VFAT (mkfs.vfat), or something else the "standard"?

mkfs.fat is the standard tool, and it is the same thing as mkfs.vfat only under a new name. "VFAT" in Linux just means "FAT12/16/32 with long filename support".

So you can use either (or even mkdosfs which is again the same tool), you will end up with the same filesystem type – for any large partition it'll be FAT32. It will be compatible with pretty much everything except ancient MS-DOS.

(There is also a FAT format tool in GNU mtools, but it is meant for FAT12 floppy disks, uses unusual parameters like a much smaller root directory size, and is unlikely to give good results for USB sticks.)

Microsoft is pushing exFAT(mkfs.exfat) for larger drives (my drive is 128GB) now, right? However, I hear exFAT is not supported by the kernel on some linux distros (in my case Raspbian). It would be nice to not need to use FUSE to mount, which I understand is for exFAT.

FUSE is currently needed for exFAT, but this is likely to change soon (one driver is already in staging/ for v5.4 and a better one might soon replace it). However the FUSE driver works well and you don't need any special commands to use it: it's just the same mount -t exfat, or just mount as libblkid will recognize it as exFAT regardless of driver.

Same goes for NTFS: the kernel has a driver, but the FUSE-based NTFS-3g works a bit better and is also seamless (taking over mount -t ntfs).

We can ignore issues with making sure data is all written to the drive / clean unmounting for now, but it might be nice to touch on this

umount will always do the right thing.

The Linux FAT driver accepts the flush mount option which will try to sync changes every time a file is closed after write, which – like on Windows – should let you unplug the drive as soon as it goes idle. (Although doing so will still leave the "dirty" flag set on the filesystem in any case.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.