Modern Linux systems organize persistent data in several layers, from the raw storage device up to the file system that user-space programs see. At a high level these layers are:

At the lowest level there is a physical storage device. This can be a spinning hard disk, a SATA SSD, an NVMe drive on a PCIe bus, or some other kind of non-volatile memory. The important property of this device is that it can keep its data when you power down the PC, and that it exposes a large range of addresses where data can be stored.

Internally, the hardware groups data into fixed-size units often called sectors (commonly 512 bytes or 4096 bytes), but user space applications normally do not work directly with those details. The device is driven by a microcontroller and a kernel driver that know how to send commands to it and how to handle errors.

The Linux kernel wraps physical storage in a more generic abstraction called a block device. A block device is something you can read and write in fixed-size chunks called blocks. The block size is usually equal to, or a multiple of, the sector size that the hardware uses. From the kernel’s point of view, "block device" is a generic interface: the same kernel code can work with many different kinds of disks and SSDs, as long as there is a driver that presents them as block devices. In user space, these devices appear as special entries under /dev (for example /dev/sda or /dev/nvme0n1).

A single block device is often divided into multiple regions called partitions. A partition is just a contiguous range of blocks on a block device that has been marked for separate use. Information about how the disk is divided is stored in a partition table near the beginning of the disk. The partition table is a small data structure that lists where each partition starts, how large it is, and what type it is meant to hold. Common partition table formats are used in practice, but the important idea here is that each partition is treated by the kernel as if it were its own block device. For example, /dev/sda1 and /dev/sda2 are separate partitions on the same underlying disk /dev/sda. This allows different operating systems (or different parts of the same system) to live on different regions of the same physical device.

Plain partitions are fixed slices of a disk: once you choose their sizes and positions, changing them later is possible but risky and often requires downtime or careful manual work.

Above plain partitions you can add another layer: logical volume management. Instead of putting file systems directly on partitions, you can group one or more physical devices into a pool and carve out logical volumes from that pool. A logical volume is a virtual block device created by a volume manager. The kernel and user-space see it as just another block device, but internally the volume manager can map it to multiple disks, move it around, resize it or keep snapshots.

With logical volumes, the file system sits on top of a virtual block device that can grow, shrink, be moved to different physical disks or even be spread across several disks, while the file system itself and the applications using it do not need to know how the underlying storage changed.

On Linux, a common volume manager is LVM (Logical Volume Manager). Some modern file systems integrate volume management features directly. Btrfs is an example of this. Btrfs can take multiple devices, manage them as a single storage pool, and provide subvolumes and snapshots inside that pool. In that model, you do not necessarily need a separate tool like LVM, because the file system itself understands the idea of multiple devices and logical subdivisions. The underlying principle is the same: decouple the "logical volume" that the file system sees from the raw layout of blocks on the physical devices.

At the top of these storage layers sits what it's usually called the file system. In the kernel, a file system is implemented as a driver that knows how to use a block device to store and organize data. The driver does not care whether the underlying block device comes from a plain disk, a partition, or a logical volume. It just sees something that can read and write fixed-size blocks and builds its own layout on top.

Each file system type (for example ext4, XFS or Btrfs) defines its own on-disk format. The on-disk format is simply the specific way in which that file system arranges data and bookkeeping information across the blocks. The file system driver understands that format. When other parts of the kernel ask it to create, remove or update files, the driver translates those requests into sequences of block reads and writes on the underlying device.

In this way, the lower layers (physical storage, block devices, partitions and logical volumes) are responsible for providing a reliable range of blocks, and the file system driver is responsible for deciding how those blocks are used. The rest of the kernel does not need to know how the blocks are arranged internally; it just calls into the file system driver, which hides the details of the on-disk format and presents a consistent view of stored data as directories and files.