A disk partition can contain an ext4 filesystem while a process sees an overlay filesystem at /. Meanwhile, /proc/filesystems may list tmpfs and nfs, neither of which needs a local partition. These are not conflicting answers. They describe different parts of the Linux storage stack.

The distinction matters when identifying a volume, investigating an unexpected mount, or checking which filesystem handles an application’s path. A filesystem signature on a device is not the same thing as a mounted filesystem in a process’s namespace.

A device, a mount, and a filesystem driver answer different questions

For a conventional local volume, the relationship is roughly:

block device (/dev/sdb1)
    |
    | filesystem metadata: ext4
    v
kernel filesystem driver
    |
    | mounted at /srv/data
    v
pathnames beneath /srv/data

This picture is deliberately limited to an ordinary block-backed mount. Linux also supports virtual filesystems, network filesystems, stacked filesystems, and filesystems spanning more than one device.

Three questions follow from these layers:

  • What content does a block device appear to hold?
  • Which mounted filesystem handles a particular pathname?
  • Which filesystem types can the running kernel currently use?

No single command answers all three.

lsblk and blkid inspect storage identities

lsblk enumerates block devices. Its filesystem columns are populated from available metadata, commonly through udev or probing with libblkid.

lsblk -o NAME,TYPE,FSTYPE,UUID,MOUNTPOINTS

FSTYPE describes recognized content on a block device. A partition may have FSTYPE=ext4 even when it is not mounted anywhere. MOUNTPOINTS adds mount associations, but it does not turn lsblk into a complete inventory of virtual or network mounts.

For direct inspection of a specific device, blkid reports detected content signatures and attributes:

sudo blkid /dev/sdb1

An ext4 volume might report TYPE="ext4" and a UUID. That is evidence about the device’s content; it does not establish that the volume is currently mounted or where it is visible.

Not every FSTYPE value names a mountable ordinary filesystem. An encrypted partition can report crypto_LUKS, while its unlocked device-mapper mapping contains the actual ext4 or XFS filesystem. Likewise, swap has a recognized on-disk signature but is not mounted as a directory tree.

For non-root users, blkid may return cached, unverified information rather than direct probing results. If recently rewritten media produce conflicting signatures, low-level blkid -p probing and wipefs -n can help identify old metadata without erasing it. Neither a stale signature nor a cached value should be confused with the active mount state.

findmnt identifies the filesystem serving a path

A pathname is resolved through the calling process’s mount namespace. To inspect the filesystem currently covering a directory:

findmnt --target /srv/data -o TARGET,SOURCE,FSTYPE,OPTIONS

The --target option finds the mount that contains the given path, even when that path is not itself a mount point. Use --mountpoint when the question is whether a specific directory is an exact mount point.

findmnt normally obtains active mount information from /proc/self/mountinfo. Its FSTYPE therefore describes the mounted filesystem associated with the selected pathname. It does not merely repeat a block device’s stored signature.

df -Th also reports filesystem types in the context of mounted filesystem space accounting. It is useful for capacity questions, but it is not a catalog of all formatted devices.

This explains a common observation: lsblk can show ext4 on an unmounted partition, while findmnt --target /srv/data reports the filesystem of the parent directory. The ext4 signature exists; it simply is not serving that path.

Virtual and stacked filesystems break the disk-to-path assumption

A mount need not have a dedicated local block device:

  • tmpfs stores its file data in memory-backed storage managed by the kernel, with swapping possible.
  • proc and sysfs expose kernel and process information through filesystem interfaces.
  • nfs provides a filesystem backed by a remote server.
  • overlay combines directory layers into a merged filesystem view, commonly used by containers.

Inside a container, findmnt --target / may report overlay even when the host stores the backing directories on ext4 or XFS. Asking lsblk for the host block-device type and asking findmnt for the container root mount are different operations at different layers.

Mount namespaces add another boundary. /proc/self/mountinfo describes the mounts visible to the process reading it. A host process and a container process can report different mount trees without any change to disk formatting.

/proc/filesystems is a kernel capability list

cat /proc/filesystems

This file lists filesystem types built into the running kernel or provided by modules that are currently loaded. It is not a list of volumes and does not indicate that each listed type is in use.

Entries marked nodev do not require a block device for mounting. The marker is not a claim that the filesystem never stores data: a network filesystem, for example, can have persistent storage on another machine.

A filesystem module absent from the current list may become available after its module is loaded. Conversely, a listed driver says nothing about whether a particular device contains a valid instance of that filesystem.

Choose the command by the object being investigated

Question Appropriate inspection
Which block devices exist, and what signatures were recognized? lsblk -o NAME,TYPE,FSTYPE,UUID,MOUNTPOINTS
What metadata is detected on a specific block device? sudo blkid /dev/sdb1
Which mounted filesystem serves this path? findmnt --target /srv/data -o TARGET,SOURCE,FSTYPE
What type and space usage does a mounted volume report? df -Th
Which filesystem drivers are currently registered? cat /proc/filesystems

Also distinguish configured mounts from active ones. /etc/fstab expresses mount configuration, including volumes that may not be mounted. It cannot replace a runtime query when diagnosing a path.

A reliable filesystem diagnosis starts with the object of interest. For an application’s data directory, inspect the path’s active mount first; then trace its source to a block device if one exists. For a newly attached disk, inspect the device signature first; only then check whether and where it was mounted. That order avoids treating a label on storage as proof of what the application is actually using.

References