VMware ESXi and vSphere Cluster Management

Obtain File System Information in Linux

Learn how to identify Linux file systems and inspect ext2, ext3, ext4, and XFS metadata with dumpe2fs, xfs_info, xfs_metadump, and xfs_mdrestore.

File system inspection is the process of reading structural information about a file system without attempting to repair it or recover ordinary user files. Linux administrators use inspection commands to understand storage layout, capacity, inode availability, journaling, feature flags, mount history, UUIDs, and other diagnostic metadata.

This lesson focuses on ext2, ext3, ext4, and XFS. The correct command depends on the file system type, so identify the target before querying it. For background on mounted file systems and storage devices, see file system information commands.

What File System Inspection Does

File system metadata is structural information describing a file system and its contents. It includes allocation records, inode information, directory structures, journals, geometry, and feature settings. Metadata does not mean the complete contents of every regular file.

Inspection is different from several other storage tasks:

  • Inspection reads and reports metadata, such as block counts, inode counts, UUIDs, and enabled features.
  • Mounting makes a file system available at a directory in the Linux directory tree.
  • Repair modifies metadata to correct inconsistencies. Tools such as file system checkers belong to this category.
  • Data recovery attempts to retrieve user-file contents that are missing, deleted, or inaccessible. A metadata dump is not a data-recovery backup.

Inspection is useful when investigating capacity problems, checking whether inode exhaustion is possible, documenting a volume, comparing feature support between systems, or collecting evidence for an offline diagnosis.

Understand the Storage Target

A block device is a device node representing a disk, partition, logical volume, or similar storage object. A disk may contain partitions, and a partition or logical volume may contain a file system. A mount point is the directory where that mounted file system appears in the directory tree.

  • /dev/sda commonly represents a whole SCSI, SATA, or virtual disk.
  • /dev/sda3 represents the third partition on that disk.
  • /dev/nvme0n1p3 represents the third partition on an NVMe device.
  • /dev/mapper/data commonly represents a device-mapper target, such as a logical volume.
  • A UUID-based reference identifies a file system independently of its current device name and is often used in /etc/fstab.
  • /srv/data is a directory and may be the mount point for one of the devices above; it is not itself the block device.

Do not assume that a whole disk, partition, logical volume, and mount point are interchangeable. Passing the wrong layer to a metadata tool can produce an error or, worse, lead to investigation of the wrong file system.

Identify the File System Before Inspection

Use several views when the storage layout is unfamiliar. The output from one command can be correlated with another before selecting a diagnostic tool.

lsblk -f
blkid
findmnt -T /srv/data
df -T /srv/data
mount
  • lsblk -f lists block devices with file system type, label, UUID, and mount point information.
  • blkid reports detected signatures and identifiers on block devices.
  • findmnt -T /srv/data maps a directory to the mounted source device and file system type.
  • df -T /srv/data shows the file system type alongside mounted capacity information.
  • mount displays current mounts and their options.

For example, to confirm the device backing an ext4 mount:

findmnt -T /srv/data
lsblk -f

Look for the source device, the file system type, the UUID, and the target directory. Select dumpe2fs for ext2, ext3, or ext4. Select xfs_info for a mounted XFS file system. Do not use dumpe2fs on XFS or use XFS tools on an ext file system.

Choose the Appropriate Tool

dumpe2fs — ext2, ext3, ext4 — Block device — Reports ext superblock and group metadata — Generally suitable for a mounted ext file system — Does not copy user-file contents.

xfs_info — XFS — Usually a mounted directory — Reports XFS geometry and features — Requires access to a mounted XFS file system in common environments — Does not copy user-file contents.

xfs_metadump — XFS — Source device and destination dump file — Creates a metadata-focused diagnostic dump — Source should be unmounted or mounted read-only — Does not preserve normal file data, although names and structural details may be present.

xfs_mdrestore — XFS metadata dump — Input dump file and output image — Builds an analysis image from a metadata dump — Works with the dump and a disposable output path — Does not restore original user-file contents.

Inspect ext2, ext3, and ext4 with dumpe2fs

dumpe2fs is supplied by the e2fsprogs package. It reports metadata for the ext family, including ext2, ext3, and ext4.

Concise superblock summary

Use the -h option when you need the high-value superblock or header information without detailed block-group descriptors:

sudo dumpe2fs -h /dev/sdb1

The input should be the correct ext block device, such as a partition or logical volume. Without -h, the report is more verbose and includes detailed group-related information:

sudo dumpe2fs /dev/sdb1

The command reads metadata and is generally suitable for mounted ext file systems. Use appropriate privileges, verify the device carefully, and remember that reading metadata is not the same as performing a repair.

Important dumpe2fs fields

Filesystem UUID and volume name — The UUID is a persistent identifier for the file system, while the volume name is an administrator-assigned label — Match the report to inventory records, mount configuration, or a known volume.

Last mounted on — The path recorded when the file system was last mounted — Compare it with the current mount point and investigate unexpected historical paths.

Filesystem features — Compatibility and behavior flags enabled on the ext file system — Confirm that kernels and utilities on another system support the features before moving or troubleshooting the volume.

Block count and free blocks — The total number of file system blocks and the blocks currently available — Investigate block-space exhaustion and compare with df -h.

Inode count and free inodes — The total inode capacity and the number not currently allocated — Investigate cases where files cannot be created despite apparent free space.

Reserved block count — Blocks held back for privileged use or recovery purposes — Understand why ordinary users may see less usable capacity than the raw total suggests.

Mount count and maximum mount count — The number of mounts since the last check and the threshold that can trigger a routine consistency check — Assess whether scheduled checking is due.

Last checked and check interval — The timestamp of the last consistency check and the configured time interval between checks — Determine whether a periodic check may be overdue.

Journal information — Whether a journal exists and where its metadata is located — Distinguish journal-capable ext3/ext4 configurations from ext2-style configurations without a journal.

Other fields can include the file system revision, creation time, block size, inode size, operating-system-related metadata, last mount time, and last check time. Together, these fields describe both the physical organization and the administrative history of the ext file system.

Interpret ext File System Metadata

Mount counts and scheduled checks

The mount count records mounts since the last file system check. The maximum mount count is a policy threshold used with routine consistency checking. These values do not prove that corruption exists. They indicate when a scheduled check may be appropriate under the system's file system-check policy.

The last check timestamp and check interval provide a time-based view of the same policy. A high mount count or expired interval is a reason to plan an appropriate check, not a reason to run a repair command blindly on a busy production volume.

Blocks versus inodes

A block is a unit of storage allocation. An inode is a file system data structure containing file attributes and block-location information; directory entries associate names with inodes.

There are two distinct exhaustion cases:

  • Block-space exhaustion: free data blocks are depleted. Large files or the total amount of stored data may be the cause.
  • Inode exhaustion: free inodes are depleted. A very large number of small files, cache entries, or temporary files can cause this even when blocks remain.
sudo dumpe2fs -h /dev/sdb1
df -h /srv/data
df -i /srv/data

Compare the total and free blocks in the metadata report with mounted usage from df -h. Compare inode totals and free inodes with df -i. If disk space appears available but applications cannot create files, also check permissions, quotas, and whether the mount has become read-only.

Reserved blocks, journals, and feature flags

Reserved blocks are held aside for privileged use or recovery. They can help preserve administrative access and provide working space when ordinary users have consumed nearly all available blocks. Consequently, the raw free-block count and the space available to an ordinary process are not always identical.

A journal is a metadata logging mechanism that improves consistency after an interruption such as a crash or power loss. Ext3 and ext4 commonly use journaling, while ext2 does not require a journal. An ext4 file system can also be configured with feature combinations that affect how it is supported and handled.

Feature flags describe capabilities such as directory or allocation behavior and compatibility requirements. Before attaching a volume to another operating system or an older rescue environment, verify that its kernel and utilities understand the enabled features. A volume can be healthy while still being unsupported by an older tool set.

Inspect XFS with xfs_info

xfs_info is the usual information tool for XFS. It reports file system geometry, allocation-group organization, inode configuration, naming behavior, log settings, realtime settings, and enabled features.

Use a mounted directory as the target:

findmnt -T /xfs
sudo xfs_info /xfs

The mount point is often the clearest target because it identifies the active XFS instance directly. Whether a raw device is accepted can depend on the installed XFS utilities and environment, so use the mount point when the file system is mounted.

meta-data — Allocation-group count, sector size, inode size, inode allocation settings, and related metadata geometry — Shows how XFS organizes structural information and helps identify layout constraints.

data — Data block size, total blocks, allocation groups, and allocation-group geometry — Helps relate capacity and allocation behavior to the physical file system layout.

naming — Directory block size, directory format, and naming-related features — Helps diagnose directory behavior and feature compatibility.

log — XFS log or journal location, size, block size, and format — Helps assess journaling layout and possible log-related constraints.

realtime — Realtime device and extent geometry, when configured — Indicates whether a separate realtime area is present and how it is organized.

An XFS allocation group is an independently managed XFS region that supports scalable allocation and parallelism. The number and geometry of allocation groups can matter when analyzing performance, capacity distribution, or allocation behavior.

The XFS log is the journaling area. It may be internal to the file system or located on a separate device. Inode allocation settings, directory format, block sizes, and feature flags can all affect interoperability and diagnosis. Treat the output as a description of the file system's design, not as a repair operation.

Capture XFS Metadata with xfs_metadump

xfs_metadump creates a metadata-focused diagnostic dump. It is useful for offline investigation, defect reports, and analysis when copying the complete contents of a large file system would be unnecessary or undesirable.

A metadata dump can represent structural information such as allocation records, inode metadata, directory structures, and file or directory naming information. Ordinary file data is not preserved. Names and structural details can still be sensitive, so store and share the dump under controlled permissions.

The source should be unmounted or mounted read-only. A writable mounted source can change while the dump is being made, producing an inconsistent capture.

sudo umount /xfs
sudo xfs_metadump /dev/sda3 /var/tmp/xfs-metadump.img

If unmounting is not possible and operational procedures approve a read-only transition, a remount may be considered:

sudo mount -o remount,ro /xfs
sudo xfs_metadump /dev/sda3 /safe/output/xfs.metadump

Confirm the source device with findmnt and lsblk before using the command. Ensure that the destination has adequate space and is not on the source file system if that file system is being unmounted or captured.

Build an Analysis Image with xfs_mdrestore

xfs_mdrestore is the companion utility for converting an XFS metadata dump into an image that can be used for metadata-oriented inspection.

sudo xfs_mdrestore /var/tmp/xfs-metadump.img /var/tmp/xfs-metadata-restored.img

Use a disposable output path with sufficient available storage. The result is not a restored production file system and does not contain the original user-file data. It must not be treated as a backup or a substitute for conventional backups and file-recovery procedures.

Permissions and Operational Safety

  • Reading a mounted directory may work as an ordinary user, but raw block-device access commonly requires sudo or root privileges.
  • Mandatory access controls, containers, or restricted device namespaces can prevent access even when the command syntax is correct.
  • Verify the exact source before every command, especially when names such as /dev/sda2, /dev/sda3, or multiple mapped volumes look similar.
  • Information commands such as dumpe2fs and xfs_info are read-oriented; do not confuse them with repair or tuning utilities.
  • xfs_metadump has stricter source-state requirements than ordinary information queries. Prefer an unmounted source or an approved read-only mount.
  • Save evidence to a timestamped text file, while protecting any output that contains identifiers or sensitive paths.
sudo dumpe2fs -h /dev/sdb1 | tee /var/tmp/ext4-info-$(date +%Y%m%d-%H%M%S).txt
sudo xfs_info /xfs | tee /var/tmp/xfs-info-$(date +%Y%m%d-%H%M%S).txt

Practical Diagnostic Workflows

Investigate an ext4 capacity complaint

  1. Identify the mounted source and type: findmnt -T /srv/data.
  2. Confirm the block-device mapping and UUID: lsblk -f.
  3. Read the ext superblock summary: sudo dumpe2fs -h /dev/sdb1.
  4. Compare block usage: df -h /srv/data.
  5. Compare inode usage: df -i /srv/data.
  6. Review reserved blocks, mount-check information, journal fields, and feature flags in context.

Inspect a mounted XFS file system

findmnt -T /xfs
sudo xfs_info /xfs

Read the meta-data, data, naming, log, and realtime sections. Pay particular attention to allocation-group geometry, block sizes, inode settings, directory format, log placement, and feature flags.

Create and inspect an XFS metadata artifact

  1. Verify the source device and mount state.
  2. Unmount the XFS file system, or use an approved read-only mount.
  3. Capture metadata to protected storage with xfs_metadump.
  4. Restore the dump to a disposable analysis image with xfs_mdrestore.
  5. Use the image only for metadata-focused investigation, not file recovery.

Troubleshooting Common Problems

dumpe2fs rejects the target

If dumpe2fs says the target is not an ext2/ext3/ext4 file system, the wrong partition or logical volume may have been selected. The target may instead be XFS, Btrfs, swap, LVM metadata, encryption, or another format. It may also be a whole disk rather than the intended partition. Recheck with lsblk -f, blkid, and findmnt, then select the tool matching the detected type.

Permission denied

The user may lack permission to read the block device, or the current container or security policy may restrict device access. Run the read-only query through sudo if authorized, and verify that the device is visible and permitted in the current environment.

xfs_info fails with a raw device

The XFS file system may not be mounted, or the local xfs_info implementation may expect a mount point. Find the mount point with findmnt and run xfs_info against that directory. Mount the correct XFS file system first if local procedures permit it.

xfs_metadump warns about a writable mount

A read-write source can change during capture. Unmount it, or remount it read-only when safe and approved. Do not treat the dump as a backup or as a consistency check.

The restored image has no original files

This is expected. A metadump preserves structural metadata rather than regular file content. Use conventional backups or approved recovery workflows when the contents of files are required.

Exam-Relevant Summary

  • Identify the file system type before choosing a tool.
  • dumpe2fs -h reports a concise ext superblock summary; omitting -h includes detailed group information.
  • Ext block exhaustion and inode exhaustion are different problems; compare df -h and df -i.
  • Mount count, maximum mount count, last-check time, and check interval describe routine consistency-check policy.
  • Journals improve consistency after interruption, while feature flags affect compatibility with kernels and utilities.
  • xfs_info normally targets a mounted XFS mount point and reports geometry and features.
  • xfs_metadump creates a metadata-only diagnostic dump from an unmounted or read-only XFS source.
  • xfs_mdrestore creates an analysis image from that dump; neither the dump nor the restored image is a complete user-data backup.
  • Always verify the exact device, privileges, mount state, and output destination before running a command.