the superblock
Every filesystem needs one place that describes the whole filesystem rather than any single file: how big it is, what block size it uses, how many inodes exist, where the important tables live, whether it was cleanly unmounted last time. That summary record is the superblock. If a book's table of contents told you the book's title, page size, chapter count, and where each section begins, the superblock is that table of contents for an entire storage volume.
There are really two superblocks to keep straight. On disk, the superblock is a fixed, small structure (often duplicated in backup copies scattered across the volume) holding magic numbers that identify the filesystem type, the total block and inode counts, free counts, the block size, the location of the inode table and bitmaps, and a clean/dirty flag set when the filesystem is mounted and cleared on a clean unmount. In memory, the kernel keeps a VFS struct super_block, one per mounted filesystem, that points at the root dentry, holds the function pointers (super_operations) for syncing and unmounting, and caches the on-disk values so it need not re-read them constantly.
Why it matters: the superblock is the entry point fsck and the mount code read first - if it is corrupt, the filesystem may refuse to mount at all, which is precisely why filesystems keep redundant backup superblocks (you can point fsck at one with a command like fsck -b 32768). The dirty flag in the superblock is also how the system knows on the next boot that a filesystem was not unmounted cleanly and may need a journal replay or a full check.
$ sudo dumpe2fs -h /dev/sda1 Block size: 4096 Inode count: 6553600 Free blocks: 482113 Filesystem state: clean Backup superblock at: 32768, 98304, ...
dumpe2fs prints the on-disk superblock: block size, counts, clean/dirty state, and backup locations.
Free-block and free-inode counts in the superblock are summaries kept in sync with the bitmaps; a crash mid-write can leave them disagreeing, and that disagreement is one of the inconsistencies fsck or a journal replay exists to fix.