Linux concept: filesystems

1. The Basics

A filesystem is the structure a system writes onto a storage device so that raw blocks can be used as named files in folders. It is both a format on disk and the kernel code that understands that format.

Start from what the hardware offers. A disk, an SSD, a partition, an LVM volume, all present the same simple thing to the kernel: a numbered sequence of fixed-size blocks that you can read and write. Block 0, block 1, block 2, up to a few hundred million of them. There is no other structure. If you want a file called invoice.pdf that belongs to you, is 240 KB long, and lives in /home/peter/admin/, every part of that sentence has to be stored in those blocks by somebody.

The filesystem is that somebody. It decides which blocks hold your content, writes a record saying "this file is 240 KB, owned by user 1000, and its content is in blocks 900,112 to 900,171", and writes a second record in the folder saying "the name invoice.pdf refers to that record". Everything else follows from those two ideas.

1.1 What a Filesystem Actually Is

It helps to see the word used in three different ways, because Linux uses all three and they are not the same thing:

When somebody says "the filesystem is full", they mean the second one. When they say "check the filesystem", they usually mean run fsck on the second one too. When a programmer says "read it from the filesystem", they mean the third. Keeping the three apart removes a surprising amount of confusion from storage discussions.

1.2 Three Things, Not One: Data, Metadata, and Names

The single most useful idea in this article is that a file is not one object. It is three separate things that the filesystem stores in three separate places:

DIRECTORY ENTRY     "invoice.pdf"  →  inode 61743294       (the name)
        |
        v
INODE 61743294      size, owner, group, permissions, three
                    timestamps, link count, and a map of blocks   (the facts)
        |
        v
DATA BLOCKS         900112, 900113, 900114, ...                  (the content)

The directory entry is only a name plus a number. The inode holds every fact about the file except its name. The data blocks hold the bytes. A directory is not a container that holds files; it is a small table of names and inode numbers, and it is itself a file.

The right mental model: a filename is a pointer, not a file. The file is the inode plus its blocks. This one split explains hard links, why deleting is instant, why a full disk can stay full after rm, and why moving a file inside one filesystem takes no time at all.

1.3 One Tree, Many Filesystems

Windows gives each formatted volume its own letter. Linux does the opposite: there is exactly one tree, starting at /, and every other filesystem is grafted into it at a mount point, which is just an existing directory. After the graft, nothing in a path tells you where one filesystem ends and the next begins.

$ findmnt -o TARGET,SOURCE,FSTYPE
TARGET            SOURCE                             FSTYPE
/                 /dev/mapper/ubuntu--vg-ubuntu--lv  ext4
├─/boot           /dev/nvme0n1p2                     ext4
│ └─/boot/efi     /dev/nvme0n1p1                     vfat
├─/dev/shm        tmpfs                              tmpfs
└─/run            tmpfs                              tmpfs

Four different filesystems on three different kinds of storage, and one of them (tmpfs) is not on a disk at all. A user typing cd /boot/efi crosses two boundaries without noticing, which is exactly the point.

The part of the kernel that makes this work is the VFS, the Virtual File System. It defines one set of operations, open, read, write, rename, and each filesystem type implements them. Your program calls open() and never learns whether the answer came from ext4, from a USB stick formatted as FAT, from a network share, or from memory. The article on the kernel covers the VFS as one of the kernel's core jobs; here it matters because it is the reason all the commands below work the same way on every filesystem type.

1.4 What Sits Underneath

The filesystem is one layer in a stack, and storage problems are much easier to solve when you know which layer you are looking at. On the machine used for this article the stack is five deep:

$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME                         SIZE TYPE  FSTYPE       MOUNTPOINT
nvme0n1                      1.9T disk
├─nvme0n1p1                    1G part  vfat         /boot/efi
├─nvme0n1p2                    2G part  ext4         /boot
└─nvme0n1p3                  1.9T part  crypto_LUKS
  └─dm_crypt-0               1.9T crypt LVM2_member
    └─ubuntu--vg-ubuntu--lv  1.9T lvm   ext4         /

Read it from the bottom up: an ext4 filesystem lives on a logical volume, which lives in an LVM volume group, which lives inside an encrypted LUKS container, which is a partition on an NVMe disk. Each layer only sees numbered blocks from the layer below and hands numbered blocks to the layer above.

That layering is why "the disk is full" and "the filesystem is full" are different sentences, why you can grow a filesystem without touching the disk, and why encryption is invisible to ext4. It is also the order you must think in when something breaks: a disk error, a LUKS problem, an LVM problem and a filesystem problem all look like "I cannot read my files".

3. A Short History

Filesystem design has been driven by three pressures, in order: making disks usable at all, surviving a crash, and coping with disks that grew far faster than anyone planned for.

Unix from 1969 already had the inode idea, and it barely changed in fifty years. What changed was speed and safety. The original Unix filesystem scattered inodes and data across the disk and lost a great deal of time to seeking. In 1983 the Berkeley Fast File System introduced cylinder groups, larger blocks and the idea of keeping a file's metadata near its data, and made Unix disks several times faster. Nearly every filesystem since has copied that idea in some form.

Linux started with the Minix filesystem, which allowed filenames of only 14 characters and partitions of only 64 MB. That limit is why ext exists at all: Remy Card wrote the Extended File System in 1992 to escape it, then replaced it a year later with ext2, which stayed the Linux default for a decade.

The next pressure was crash recovery. On a large ext2 filesystem, an unclean shutdown meant a full fsck, and a full fsck on a big disk could take hours while the server stayed down. Journalling solved that, and ext3 (2001) added it to ext2 without changing the on-disk layout, so you could upgrade in place. ext4 (2006, stable in 2008) then added extents, delayed allocation, much larger limits and faster allocation, and is still the default on most Linux distributions today.

The third pressure was scale, and it produced a different kind of filesystem. XFS came from Silicon Graphics in 1994 for machines doing video work, was released as open source in 2000, and was built from the start for very large files and many parallel writers. ZFS (Sun, released 2005) and Btrfs (started at Oracle in 2007, in the mainline kernel from 2009) went further and merged the volume manager into the filesystem, adding checksums on everything, snapshots, and copy-on-write.

One licence detail explains a practical annoyance. ZFS is excellent and cannot be shipped inside the Linux kernel, because its CDDL licence and the kernel's GPL are considered incompatible. That is why ZFS on Linux arrives as a separate module you install and rebuild for each kernel, while Btrfs, which aims at the same goals, is simply there.

5. Moderate Use Cases: Inodes, Names and Blocks

This section takes the three-part model from section 1.2 and shows each part on a real system. Everything here works on ext4 and needs no root.

5.1 Reading an Inode with stat

ls -l shows a polished summary. stat shows the inode almost raw, and it is the tool to reach for whenever a file behaves strangely:

$ printf 'x' > tiny.txt        # a file containing exactly one byte

$ stat tiny.txt
  File: tiny.txt
  Size: 1          Blocks: 8          IO Block: 4096   regular file
Device: 252,1      Inode: 61743294    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/   pe7er)   Gid: ( 1000/   pe7er)
Access: 2026-09-06 22:14:03.840817742 +0200
Modify: 2026-09-06 22:14:03.840817742 +0200
Change: 2026-09-06 22:14:03.840817742 +0200
 Birth: 2026-09-06 22:14:03.840817742 +0200

Read that field by field, because every line is a fact the filesystem had to write down somewhere:

Notice what is not there: the filename appears only on the first line, and only because you typed it. The inode itself does not know what it is called.

5.2 A Name Is Not a File

Give the same inode a second name and both names are equally real. Neither is the original:

$ ln tiny.txt hard.txt          # a hard link: a second name, same inode

$ stat -c '%n inode=%i links=%h' tiny.txt hard.txt
tiny.txt inode=61743294 links=2
hard.txt inode=61743294 links=2

Delete either one and the data survives, because rm does not delete files. It removes a name and decreases the link count; the filesystem frees the blocks only when the count reaches zero and nobody has the file open. That is the whole mechanism behind the disk that stays full after you delete a log file, which the article on du traces in detail.

A symbolic link is a different thing entirely: its own inode, holding a path as text.

$ ln -s tiny.txt soft.txt

$ stat -c '%n inode=%i size=%s type=%F' soft.txt
soft.txt inode=61743295 size=8 type=symbolic link

Its size is 8 bytes, which is exactly the length of the string tiny.txt. That is all a symlink is: a small file whose content is a pathname, resolved fresh every time you use it. It can point across filesystems and at things that do not exist; a hard link can do neither, because an inode number means nothing outside its own filesystem.

5.3 The Metadata That Is Not in the Inode

The inode has a fixed set of fields, and for forty years that was all the metadata a file could have. Modern filesystems add a second, open-ended store: extended attributes, arbitrary name and value pairs attached to a file. They are the ext_attr feature and the user_xattr mount option that appear in the dumpe2fs output in section 6.1.

The usual tools are setfattr and getfattr from the attr package, which many distributions do not install by default. The system calls are always there, so anything can use them:

$ python3 -c "
import os
os.setxattr('tiny.txt', 'user.author', b'Peter Martin')
print(os.listxattr('tiny.txt'), os.getxattr('tiny.txt', 'user.author'))
"
['user.author'] b'Peter Martin'

Attribute names live in four namespaces, and the prefix decides who may write them:

Access control lists then turn out to be a user of this same machinery rather than a separate feature. The classic owner/group/other bits cannot express "and this one extra user may write", so ACLs add per-user and per-group entries. They are switched on by the acl mount option, which is an ext4 default:

$ setfacl -m u:root:rw tiny.txt      # give one named user write access

$ ls -l tiny.txt
-rw-rw-r--+ 2 pe7er pe7er 1 Sep  6 22:14 tiny.txt      # note the trailing +

$ getfacl -c tiny.txt
user::rw-
user:root:rw-                       # the extra entry
group::rw-
mask::rw-
other::r--

That + after the permission string is the only hint ls gives you, and it is easy to miss when you are wondering why a user can write to a file that appears to forbid it. Where is the ACL stored? In an extended attribute:

$ python3 -c "import os; print(os.listxattr('tiny.txt'))"
['user.author', 'system.posix_acl_access']

Two practical consequences. The mask entry is an upper bound on every named entry, and chmod on a file with an ACL changes the mask rather than the entries, which is why permissions can appear to change back on their own. And extended attributes are not copied by default: use cp -a (or --preserve=xattr), rsync -X, and tar --xattrs, or you will silently drop ACLs, SELinux labels and file capabilities while "copying everything".

5.4 Why a One-Byte File Costs Four Kilobytes

The filesystem hands out space in whole blocks, normally 4096 bytes, so a file of one byte occupies a full block and wastes 4095 of it:

$ du -h --apparent-size tiny.txt
1       tiny.txt              # the content

$ du -h tiny.txt
4.0K    tiny.txt              # the allocation

At one file this is a curiosity. At scale it is a budget item: 100,000 files of 100 bytes hold 10 MB of content and occupy 410 MB of disk. Directories full of PHP sessions, mail messages, thumbnails or Git objects routinely cost ten times what they weigh.

The block size is chosen when the filesystem is created and cannot be changed afterwards without reformatting. On Linux it is effectively always 4096, because that is the memory page size, and a filesystem block larger than a page has never been simple to support.

5.5 Running Out of Inodes While df Says There Is Room

Because ext4 fixes the inode count at creation, you can exhaust files while space remains. The count follows one setting in /etc/mke2fs.conf:

$ grep inode_ratio /etc/mke2fs.conf
        inode_ratio = 16384

One inode for every 16 KB of filesystem. On a 2 TB volume that is the 124.8 million inodes from section 4.2, which is generous for ordinary use. It is not generous for a mail server, and mkfs lets you say so in advance:

$ mkfs.ext4 -T news  /dev/sdb1     # one inode per 4 KB: many small files
$ mkfs.ext4 -i 4096  /dev/sdb1     # the same thing, said directly
$ mkfs.ext4 -T largefile /dev/sdb1 # one inode per 1 MB: video, backups, images

The difference is not subtle. The same 512 MB device, formatted three ways, gets 512, 32,768 or 131,072 inodes. Choose wrong in the direction of "largefile" on a mail spool and the filesystem fills at a few hundred messages while df -h shows it empty. Choose wrong in the other direction and you spend disk on an inode table nobody uses.

When a disk reports "No space left on device" and df -h disagrees, check inodes first and then find the directory responsible:

$ df -i /var
$ du --inodes -d 1 /var | sort -rn | head    # count files, not bytes

XFS avoids this class of problem entirely by allocating inodes as it goes, which is a genuine reason to pick it for a filesystem that will hold an unpredictable number of small files.

5.6 Mount Options That Matter

Options are set in /etc/fstab and shown by findmnt. A handful change behaviour enough to be worth knowing by name:

You can watch relatime being lazy. Read a freshly written file and its access time does not move, because it is not yet older than the modify time:

$ findmnt -n -o OPTIONS /
rw,relatime

$ stat -c '%x' tiny.txt
2026-09-06 22:16:06.891262059 +0200
$ cat tiny.txt > /dev/null       # read it
$ stat -c '%x' tiny.txt
2026-09-06 22:16:06.891262059 +0200      # unchanged: no write happened

That is a deliberate compromise: relatime arrived in 2007 and became the kernel default two years later. Strict atime turned every read into a write, which was expensive and pointless for almost everyone, while relatime keeps the access time useful enough for the few tools that read it.

5.7 fstab, UUIDs, and Why Device Names Are Not Trustworthy

Device names like /dev/sda2 are assigned in the order the kernel finds hardware. Add a disk, move a cable, or boot a virtual machine with a different controller, and yesterday's /dev/sdb is today's /dev/sdc. So filesystems are identified by a UUID written into their own superblock:

$ grep -v '^#' /etc/fstab
/dev/disk/by-uuid/e6894fe9-f40d-42ef-8183-6a31e0996127 /boot     ext4 defaults 0 1
/dev/disk/by-uuid/DAB0-BDC6                            /boot/efi vfat defaults 0 1

$ lsblk -f          # the same UUIDs, read from the filesystems themselves

The last two numbers on each line are worth a sentence. The first is for the ancient dump backup tool and is always 0. The second is the fsck order at boot: 1 for the root filesystem, 2 for the others, 0 for "never check". Set it to 0 on a filesystem that might not be present at boot, or on a filesystem, such as a network mount, where a boot-time check makes no sense.

One warning that costs people a lot of time: a broken fstab line stops the boot. Test a new entry with mount -a while the system is up and running, and only then reboot.

7. Something Most Users Do Not Know

7.1 Filenames Are Bytes, Not Text

Linux does not store filenames as text. It stores a sequence of bytes, and it enforces exactly two rules: the sequence may not contain a slash, because that separates path components, and it may not contain a zero byte, because that ends the string. Everything else is legal:

$ touch $'bad\xffname'          # 0xff is not valid UTF-8 at all
$ touch $'two\nlines'           # a newline inside the name

$ ls -b
bad\377name
two\nlines

Both files exist and behave normally. The kernel never checked whether the bytes spell anything; that is your terminal's job, and ls -b (short for "escape") is how you see what is really there.

This is not a curiosity but the reason for a whole family of scripting habits. A filename can contain a newline, so for f in $(ls) is broken by construction; a filename can start with a dash, so rm * can turn a file into a flag; a filename can hold invalid UTF-8, so a script that assumes decodable text will crash on it. It is why find -print0 and xargs -0 exist, and why careful scripts quote every variable.

7.2 The 255 Limit Is Bytes, So Accents Cost Double

The Namelen: 255 from section 4.1 is a byte count, not a character count. In pure ASCII the two are the same, and 255 characters fit exactly:

$ touch $(printf 'a%.0s' {1..255})     # 255 bytes: fine
$ touch $(printf 'a%.0s' {1..256})
touch: cannot touch 'aaaa...aaa': File name too long

Now use a letter that UTF-8 stores in two bytes, such as e with an acute accent, and the limit arrives at half the length:

$ touch $(printf '\xc3\xa9%.0s' {1..127})   # 127 letters, 254 bytes: fine
$ touch $(printf '\xc3\xa9%.0s' {1..128})   # 128 letters, 256 bytes
touch: cannot touch '...': File name too long

A Dutch, French or German filename can therefore be rejected at 128 characters while an English one of 255 is accepted, and an emoji, at four bytes each, gets you 63. The same arithmetic applies to the 4096-byte path limit, which is where deeply nested directories with long localised names occasionally hit a wall that looks like a bug in the application.

7.3 A New Filesystem Is Already Missing Space

Format a device and a noticeable part of it is gone before you write a single file. The 512 MB test image from section 6.1 says so plainly:

Block count:              131072       # 131072 x 4096 = 512 MiB
Free blocks:              124719       # 6353 blocks gone already = 24.8 MiB
Reserved block count:       6553       # another 25.6 MiB you cannot use
Inode count:              32768        # x 256 bytes each = 8 MiB of inode table
Total journal size:         16M        # the journal, before any data

The arithmetic closes almost exactly: 8 MiB of inode table plus a 16 MiB journal plus group bookkeeping is the 24.8 MiB that vanished. Then 5% is reserved for root on top of it, so about 10% of a fresh filesystem is spoken for.

Scale that to the 2 TB filesystem in section 4.2 and the numbers stop being cute. Its 124,829,696 inodes at 256 bytes each are 29.8 GiB of inode table, written at mkfs time and permanent. Its 5% root reserve is another 95 GiB, which is the gap between Free and Available in the stat -f output. That reserve is not waste: it keeps root able to log in and syslog able to write when the disk fills, which is precisely when you need both. On a pure data volume, where nothing depends on that safety margin, you can take most of it back:

$ sudo tune2fs -m 1 /dev/sdb1     # reduce the root reserve from 5% to 1%

Do that on a data disk. Do not do it on the root filesystem.

7.4 FAT Rounds Every Timestamp to Two Seconds

The FAT format stores a modification time in 16 bits, and spends only five of them on seconds, so it counts in units of two. You can prove it without a USB stick, using an image and the mtools package, which reads FAT without mounting:

$ truncate -s 64M fat.img && mkfs.vfat -F 32 -n TESTFAT fat.img
$ for s in 01 02 03; do
>   touch -d "2026-01-01 10:00:$s" t$s.txt
>   mcopy -m -o -i fat.img t$s.txt ::/      # -m preserves the timestamp
> done

Now read the raw 16-bit time field out of each directory entry, at offset 22, and decode it:

$ python3 -c "
d = open('fat.img','rb').read()
for n in (b'T01     TXT', b'T02     TXT', b'T03     TXT'):
    i = d.find(n); t = int.from_bytes(d[i+22:i+24], 'little')
    print(n.decode(), '%02d:%02d:%02d' % (t>>11, (t>>5)&63, (t&31)*2))
"
T01     TXT 10:00:00      # 10:00:01 rounded down
T02     TXT 10:00:02
T03     TXT 10:00:02      # 10:00:03 rounded down too

Three files written one second apart, two distinct timestamps. This is why a backup or sync tool that compares modification times across a FAT-formatted stick reports files as changed when nothing changed, and why rsync has a --modify-window=1 option that exists almost entirely for this.

The same directory entry shows the other FAT compromise. Every long name is stored twice, as a classic 8.3 name plus hidden extra entries holding the real one:

$ mdir -i fat.img ::/
MYLONG~1 TXT         6 2026-09-06  22:16  MyLongFileName.txt
tiny     txt         1 2026-09-06  22:16

And because FAT compares names case-insensitively, MyLongFileName.txt and mylongfilename.TXT are the same file there and two different files on ext4. Copy a directory from Linux to a USB stick and files can silently overwrite each other for that reason alone.

7.5 Your Filesystem Counts Every Byte Ever Written to It

ext4 keeps a lifetime write counter in its superblock and exposes it through /sys, no root needed:

$ cat /sys/fs/ext4/dm-1/lifetime_write_kbytes
19500766413                        # about 18.2 TiB since this disk was formatted

$ cat /sys/fs/ext4/dm-1/session_write_kbytes
6183360                            # about 5.9 GiB since the last mount

That first number is a genuinely useful figure on an SSD, where endurance is quoted in total bytes written. It is also a quiet reminder of how much writing an ordinary desktop does: eighteen terabytes through a filesystem whose owner has never deliberately written more than a few hundred gigabytes.

The same directory holds the rest of ext4's live knobs and counters, and /sys/fs/ext4/features/ lists what your kernel's ext4 driver can do, which is not the same as what your filesystem was created with.

7.6 ext4 Can Be Case-Insensitive, and ext3 Runs Out of Time in 2038

Two features that contradict what most people assume about ext4.

The first is casefolding. Since Linux 5.2 ext4 can compare names case-insensitively, per directory, which exists mainly so that Wine and Android can run software that expects Windows behaviour. It is off unless the filesystem was created with it:

$ mkfs.ext4 -q -F -O casefold cf.img
$ dumpe2fs -h cf.img | grep features
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent
                     64bit flex_bg casefold sparse_super large_file huge_file ...

The second is the year 2038 problem. A 32-bit signed timestamp counting seconds from 1970 overflows on 19 January 2038. ext4 escaped it by using 256-byte inodes with extra timestamp bits, which push the limit to the year 2446:

$ touch -d '2100-06-01 12:00:00' future.txt
$ stat -c '%y' future.txt
2100-06-01 12:00:00.000000000 +0200        # accepted without complaint

An old ext3 filesystem, or an ext4 one created long ago with 128-byte inodes, has no room for those bits and stops at 2038. The inode size is fixed at creation and cannot be changed, so the only fix is to recreate the filesystem. It is worth checking the Inode size line in dumpe2fs on any server whose disks were formatted more than a decade ago.

7.7 Your SSD May Never Be Told What You Deleted

An SSD cannot overwrite a block; it can only erase a large region and rewrite it. So the controller needs to know which blocks no longer hold anything useful, or it spends its life carefully preserving data that was deleted months ago. TRIM, also called discard, is the filesystem telling the device "these blocks are free now".

Whether that message arrives is another question, and the answer is per layer. lsblk -D prints the discard limits of every layer in the stack, and on this machine the chain breaks:

$ lsblk -D -o NAME,DISC-GRAN,DISC-MAX,MOUNTPOINTS -e7
NAME                        DISC-GRAN DISC-MAX MOUNTPOINTS
nvme0n1                          512B       2T
├─nvme0n1p1                      512B       2T /boot/efi
├─nvme0n1p2                      512B       2T /boot
└─nvme0n1p3                      512B       2T
  └─dm_crypt-0                   512B       0B
    └─ubuntu--vg-ubuntu--lv      512B       0B /

The disk and its partitions accept discards up to 2 TB. The LUKS layer on top of them reports 0B, and so does the logical volume above it. The root filesystem on this laptop has never trimmed anything, and never will while the stack looks like this, because LUKS drops discard requests unless it is opened with --allow-discards.

That default is deliberate rather than an oversight. Passing discards through encryption tells anyone who can read the raw device which blocks are unused, which leaks the filesystem's shape and how full it is, and that is information an encrypted volume is supposed to keep. The trade is real: pass discards through and the SSD stays fast, or keep them and give up a little of what encryption was for.

Where discards do get through, prefer the weekly batch job over the mount option: fstrim walks the free space once, while discard issues a command on every delete and can stutter on some hardware.

$ systemctl is-enabled fstrim.timer
enabled

$ sudo fstrim -av                 # trim every mounted filesystem that supports it

One more thing this makes clear: the filesystem does not decide where your data physically lands. The SSD's own translation layer does the placement, wear levelling and garbage collection, and it does not tell the filesystem about any of it. Every block number in section 6.2 is a fiction the device maintains for your convenience.

7.8 Crossing to Windows and macOS

Most Linux servers are administered from a Mac or a Windows laptop, and files move between the three all day. You do not need to know how NTFS or APFS work inside to do that safely, but you do need to know where they disagree with Linux, because each disagreement produces a bug that looks like something else entirely.

Case is the first one. Linux compares filenames byte for byte, so Logo.png and logo.png are two different files. NTFS and APFS are case-insensitive by default, so on a laptop they are one file. A web page that asks for logo.png while the repository contains Logo.png therefore works perfectly on the developer's machine and returns 404 on the server, and nothing on the laptop will ever warn about it. Section 7.4 showed the same collision on a FAT stick; this is the version that reaches production.

Unicode normalisation is the second, and it is nastier because you cannot see it. The letter e with an acute accent can be stored as one character, or as a plain e followed by a combining accent. macOS normalises filenames so both spellings land on the same file. Linux stores exactly the bytes it was given:

$ printf 'nfc' > "$(printf 'caf\xc3\xa9')"     # e-acute as one character
$ printf 'nfd' > "$(printf 'cafe\xcc\x81')"    # plain e plus a combining accent

$ ls -1 | grep caf | while IFS= read -r f; do
>   printf '%s  %s  %s\n' "$f" "$(printf '%s' "$f" | xxd -p)" "$(cat -- "$f")"
> done
café  63616665cc81  nfd
café  636166c3a9    nfc

Two files, one directory, identical on screen, different bytes. Copy a tree from a Mac to a Linux server and a filename typed on the server can fail to match the one that arrived, with the error "no such file" for a file you are looking straight at. It is also why git status on such a tree sometimes reports the same file as both deleted and untracked.

Legal names are the third. Linux forbids exactly two things in a filename, the slash and the zero byte. Windows forbids a good deal more, and Linux will happily create every one of them:

$ touch 'CON' 'aux.txt' 'a:b.txt' 'what?.txt' 'trailing.' 'space '
$ ls -b
a:b.txt
aux.txt
CON
space\ 
trailing.
what?.txt

All six are ordinary files here and none of them can exist on Windows. The characters < > : " / \ | ? * are forbidden there, as are control characters, a trailing dot and a trailing space, and so are the old device names CON, PRN, AUX, NUL, COM1 to COM9 and LPT1 to LPT9, with or without an extension. A backup tar from a Linux server can therefore refuse to extract on a Windows machine, and the file that stops it is usually a log or an export with a colon in a timestamp.

And metadata mostly does not survive at all. Ownership, permission bits, symlinks and the extended attributes from section 5.3 have no place to live on FAT or exFAT, and what ls -l shows on such a volume is invented by the mount options. macOS works around this by writing its own metadata into companion files, which is why a USB stick that has visited a Mac is full of ._filename entries and .DS_Store files that mean nothing to Linux.

Finally, what Linux can actually read. Three of the four foreign filesystems have a driver in the mainline kernel, and the missing one is the one people ask about most:

$ for m in ntfs3 exfat hfsplus apfs; do printf '%-8s ' $m; modinfo -F filename $m 2>/dev/null || echo "(no module)"; done
ntfs3    /lib/modules/6.11.0-29-generic/kernel/fs/ntfs3/ntfs3.ko.zst
exfat    /lib/modules/6.11.0-29-generic/kernel/fs/exfat/exfat.ko.zst
hfsplus  /lib/modules/6.11.0-29-generic/kernel/fs/hfsplus/hfsplus.ko.zst
apfs     (no module)

All of which gives one boring rule that removes every problem in this section at once: for anything that will cross between the three, use lowercase ASCII names, no spaces, no colons, and no trailing dots. It looks like superstition until the day a deployment fails on a capital letter.

7.9 The Filesystem in Your Pocket

Here is the fact that reorganises this whole subject: Android is Linux. Not Linux-like, not Linux-inspired. A phone runs the same kernel, the same VFS, the same inodes, the same extents and the same page cache described in every section above, usually on ext4 or F2FS. The userspace on top is Android's own rather than GNU, but the filesystem layer is the one this article has been taking apart. If you understand a Linux server's storage, you already understand roughly ninety percent of a phone's.

The differences are worth the other ten percent, and they start with the flash chip. A phone stores data in eMMC or UFS memory, which cannot overwrite a block and erases in large regions, exactly like the SSD in section 7.7, and which hides that behind a translation layer in the same way. F2FS is the filesystem written for it: it is log-structured, meaning it does not scatter updates across the device but appends them sequentially into large segments and reclaims old segments in the background. That pattern is the one flash hardware is fastest at, and it is why a filesystem designed by Samsung in 2012 for phones is now common on the data partition of Android devices while ext4 remains widespread elsewhere on the same phone.

You do not need a phone to meet it. The driver is on your laptop:

$ modinfo -F filename f2fs
/lib/modules/6.11.0-29-generic/kernel/fs/f2fs/f2fs.ko.zst

And the traffic runs the other way too. Section 7.5 pointed at /sys/fs/ext4/features/ without saying what is in it. Look at three of the entries:

$ ls /sys/fs/ext4/features/ | grep -E 'casefold|encryption|verity'
casefold
encrypted_casefold
encryption
test_dummy_encryption_v2
verity

All three exist largely because of Android, and they are sitting in the ext4 driver of an ordinary Ubuntu laptop:

Three more differences change how a phone feels compared with a server, and each is a layer bolted on top of the filesystems in this article rather than a new kind of filesystem:

• /sdcard is not an SD card. On a modern phone it is emulated storage that lives inside the data partition and is presented to apps through FUSE, the mechanism from section 4.4. That indirection is where per-app permission filtering happens, and it is why file access on Android is slower than the raw filesystem underneath it.
• The system partition is read-only and verified. Android mounts it through dm-verity, a device-mapper target that checks every block against a signed hash tree as it is read. It is the same device-mapper layer that carries LUKS and LVM in the stack in section 1.4, used for integrity instead of encryption.
• Every app is a Unix user. Android gives each installed application its own UID and relies on ordinary POSIX file permissions to keep app data private. The permission bits from section 5.1 are doing the work; the phone just never shows them to you.

Apple went the other way. iPhones and iPads have run APFS since iOS 10.3 in 2017, the same filesystem as the Macs in section 7.8, with the same copy-on-write clones and snapshots from section 6.7. The difference is that iOS presents no filesystem to the user at all: there is no path to type, and the Files app is a curated view rather than a window onto a tree.

So the honest summary of mobile storage is that there is much less of a difference than the marketing suggests. One of the two big phone platforms runs the filesystems in this article on hardware that behaves like a small SSD, and has pushed three features back into the ext4 driver on your desktop. The other runs the filesystem from the Mac section and simply hides it.

7.10 Knowing Where the Filesystem Stops

That last row is the one people skip. When a filesystem reports errors, the cause is often a layer below it, and smartctl -a /dev/nvme0n1 answers a question no filesystem tool can.

9. Common Mistakes

9.1 Myth versus Reality

9.2 Other Traps to Avoid

• Copying files onto a mount point that is not mounted. The write succeeds into the underlying directory, then the real filesystem mounts over it and the data vanishes from view while still using space. Check with findmnt before writing.
• Formatting with the default inode ratio for a mail or cache volume. Inodes run out at a few million files and cannot be added afterwards.
• Copying a sparse virtual disk without --sparse=always. The holes become real zeroes and a small image turns into a full-size one.
• Assuming a FAT stick preserves ownership and permissions. It stores neither. What ls -l shows there comes from the uid, gid, fmask and dmask mount options, not from the disk.
• Growing the filesystem without growing the volume underneath. The order is always: extend the partition or logical volume first, then resize2fs or xfs_growfs.
• Running e2fsck "just to check" on a mounted root filesystem. It can destroy a filesystem that had nothing wrong with it.
• Trusting du on a snapshotted or deduplicated volume. It walks names, and snapshots have none. Use btrfs filesystem usage or zfs list -o space.
• Storing a database or VM image on a copy-on-write filesystem without thinking. Random rewrites into a CoW file fragment badly; use chattr +C on the directory, or a subvolume with CoW disabled.
• Deploying a repository built on a case-insensitive laptop. Logo.png and logo.png are one file on macOS and Windows and two on Linux, so the 404 appears only in production. Fix the case in the repository, not on the server.
• Assuming a Mac can be plugged in and read. APFS has no driver in the Linux kernel. Plan for a network copy rather than discovering it with the disk in your hand.
• Missing the + in ls -l. It means an ACL grants access the permission bits do not show. Run getfacl before concluding that permissions are broken.
• Benchmarking a filesystem twice and believing the second number. The page cache and the dentry cache make every repeat run faster. Compare cold with cold, or do not compare.
• Deciding a file is missing because ls shows nothing. A leading dash, a trailing space or a newline in the name is common enough to check with ls -b before panicking.