Obtain ext and XFS File System Information in Linux

Learn how to inspect ext2, ext3, ext4, and XFS metadata safely with dumpe2fs, xfs_info, xfs_metadump, and xfs_mdrestore.

Linux file systems maintain metadata: structural information describing file-system identity, capacity, files, directories, allocation, and configuration. Metadata is different from ordinary file contents. Inspecting metadata can help administrators diagnose storage problems, verify features, and plan repairs without reading every user file.

This lesson covers the ext2, ext3, and ext4 family and XFS. Before starting, be comfortable with Linux file structure, mount points, block devices, and administrative commands run with sudo.

Choose the Utility by File-System Type

First identify the file-system type and the device or mount point that represents it. A block device is a path for a disk, partition, logical volume, or similar storage target, such as /dev/sda3.

lsblk -f
findmnt -T /srv

lsblk -f lists file-system types, labels, UUIDs, and mount points. findmnt -T /srv reports the source device and file-system type used for the path /srv.

Utility	Supported file system	Primary purpose	Input target	Mount-state requirement	Main output
`dumpe2fs`	ext2, ext3, ext4	Display ext superblock and, optionally, block-group information	Block-device path	Normally safe for read-only inspection while mounted; state can change during activity	Header fields and group descriptors
`xfs_info`	XFS	Display XFS geometry and feature information	Mounted XFS mount point	Must be mounted	Metadata, data, inode, directory, log, and feature details
`xfs_metadump`	XFS	Create a metadata-only diagnostic dump	Source device or file system and destination dump file	Use an unmounted or read-only-mounted source	Separate dump containing XFS metadata, not ordinary file data
`xfs_mdrestore`	XFS metadata dump	Reconstruct a metadata-only image for examination	Dump file and destination image	Used as an offline analysis operation	Metadata-only file-system image

Important: These utilities are information-gathering or diagnostic tools. Do not confuse them with repair tools such as fsck-family utilities or xfs_repair, or with configuration-changing tools such as tune2fs.

Inspect ext2, ext3, and ext4 with dumpe2fs

dumpe2fs displays metadata for ext2, ext3, and ext4 file systems. Its input is normally the block-device path containing the file system, not a directory.

Concise header inspection

sudo dumpe2fs -h /dev/sdb1

The -h option limits the output to the file-system header. It avoids the long block-group descriptor listing, making it useful for a quick administrative review.

The header includes information from the superblock, the core metadata structure that records file-system identity, size, features, and state. Review fields such as:

File-system type, identity, feature flags, and OS creator.
File-system state and whether the system considers it clean or requiring attention.
Last mount time, last check time, check interval, and related check information.
Total and available block counts, inode counts, and block size.
Reserved block counts or percentages.
UUID, which identifies the file system independently of its device name.
Journal presence, size, location, and other journal settings.

An inode is a metadata record describing a file or directory and its storage-related attributes. Block and inode totals help explain capacity and file-count limits. A journal is a record of metadata updates used to support consistency and recovery after an interruption.

Full ext metadata listing

sudo dumpe2fs /dev/sdb1

Without -h, dumpe2fs includes block-group descriptor details. This can produce substantially more output and is appropriate when investigating low-level layout, group-level allocation, or metadata anomalies.

dumpe2fs is typically safe for read-only inspection of a mounted ext file system. However, a mounted file system may be changing while it is being inspected. Mount times, state information, counters, and other activity-related values can therefore be time-sensitive. For incident work, record the command, device, mount state, and time of collection.

File system family	Field or output area	What it indicates	Why it is useful
ext2/ext3/ext4	Superblock state and check information	Whether the file system is marked clean and when checks or mounts occurred	Helps assess recent activity and whether consistency checking may need planning
ext2/ext3/ext4	Inode and block counts	Logical capacity and the number of file metadata records	Helps identify space or inode pressure
ext2/ext3/ext4	Journal information	Journal presence and configuration	Shows how metadata updates and recovery are organized
XFS	Allocation-group and data geometry	How XFS divides and addresses storage	Important for capacity planning and repair analysis
XFS	Inode, directory, naming, and log configuration	How file records, directories, names, and the journal-like log are configured	Useful for compatibility and behavior checks
XFS	Feature flags	Optional capabilities enabled on the file system	Important when checking kernel, tool, and repair compatibility

Inspect a Mounted XFS File System with xfs_info

xfs_info reports geometry and enabled features for a mounted XFS file system. Supply the mount point rather than an unmounted raw device.

sudo xfs_info /srv

The output is organized into several useful groups:

Metadata geometry: foundational XFS layout and metadata parameters.
Allocation groups: XFS subdivisions used to organize space and metadata management.
Data section geometry: data-space size, block size, and related layout values.
Inode configuration: inode size, alignment, and related settings.
Directory configuration: directory block and naming behavior.
Log configuration: the XFS log, which records metadata updates for consistency and recovery.
Naming version: the directory and name-handling format in use.
Enabled features: optional capabilities that affect behavior and compatibility.

Geometry matters when planning capacity, evaluating how storage is distributed, or preparing repair work. Feature flags matter when checking whether the running kernel and installed XFS utilities can safely understand the file system. Save the output before a repair or migration so that the layout and feature context is documented.

Create an XFS Metadata Diagnostic Dump

xfs_metadump writes XFS metadata to a separate dump file. It does not create a copy of ordinary file data and is not a backup that can restore user files.

Basic command form

sudo xfs_metadump SOURCE DESTINATION

SOURCE identifies the XFS source device or file system, while DESTINATION is the dump file to create. For example:

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

Metadata represented in a dump can include directory structure, names, inode-related information, allocation metadata, and size-related metadata. These details can be enough for support engineers or offline tools to examine structural problems without copying the contents of every regular file.

Required source state

Use an unmounted XFS file system or one mounted read-only. A read-only mount prevents writes and helps produce a stable diagnostic capture.

sudo mount -o remount,ro /srv
sudo xfs_metadump /dev/sda3 /var/tmp/xfs-sda3.metadump

Use the remount command only when it is operationally appropriate. It can disrupt applications that require write access. If the file system must remain available, plan downtime or use a suitable storage snapshot workflow that provides a consistent source.

Metadata captures can expose sensitive file names, directory structure, inode information, and other structural details. Store the dump with controlled permissions, protect it during transfer, and share it only with authorized personnel. Avoid placing diagnostic output on the file system being examined if that could consume needed space or complicate incident response. Prefer a separate file system with sufficient free space.

Reconstruct a Metadata-Only Image with xfs_mdrestore

xfs_mdrestore is the companion utility for turning an XFS metadata dump into a metadata-only file-system image for examination.

sudo xfs_mdrestore /var/tmp/xfs-sda3.metadump /var/tmp/xfs-sda3.img

The resulting image is an analysis artifact. It contains structural metadata represented by the dump, not the original contents of ordinary files. Do not treat it as a usable restoration, deleted-file recovery image, or replacement for a verified backup.

Command	Can inspect a mounted file system?	Required precautions	Does it copy file data?
`dumpe2fs`	Generally yes for read-only inspection	Confirm the target is ext2, ext3, or ext4; remember that changing activity can make values time-sensitive	No ordinary file data copy
`xfs_info`	Yes, and the target must be mounted	Use the correct XFS mount point and verify the mount before inspection	No
`xfs_metadump`	Do not use on a writable mounted source	Unmount the source or mount it read-only; protect the resulting dump	No; it captures metadata only
`xfs_mdrestore`	Used for offline image creation and analysis	Use a controlled destination with enough space and restricted access	No; it reconstructs only the metadata represented in the dump

Safe Inspection Workflow

Identify the target: use lsblk -f or findmnt -T PATH to verify the device, file-system type, UUID, and mount point.
Check the mount state: determine whether the source is mounted read-write, mounted read-only, or unmounted.
Choose the matching utility: use dumpe2fs for ext2/ext3/ext4, xfs_info for a mounted XFS target, and xfs_metadump for a safe XFS metadata capture.
Separate inspection from modification: do not substitute repair or configuration-changing commands when you only need information.
Protect output: write dumps and logs to a separate location when possible, ensure adequate free space, and restrict access.
Record context: save the command, timestamp, source, mount state, and relevant output for comparison or support escalation.

Exam-relevant note: xfs_info requires a mounted XFS file system, while xfs_metadump requires an unmounted or read-only-mounted XFS source. dumpe2fs -h shows the ext header without the verbose group-descriptor listing.

Troubleshooting Common Problems

dumpe2fs says the target is not an ext file system

The partition may be wrong, the target may be XFS or another format, or the path may identify an entire disk instead of the intended partition or logical volume. Run:

lsblk -f
findmnt -T /srv

Use xfs_info when the verified target is XFS.

xfs_info fails because the target is not mounted

xfs_info expects a mounted XFS mount point. Locate the active mount point with findmnt. If the file system is intentionally offline, use an XFS utility suited to the offline operation rather than passing an unmounted device to xfs_info.

xfs_metadump is attempted on a writable mounted source

Stop and change the source state first. Unmount it, or remount it read-only if that is safe for the workload. If service continuity is required, coordinate downtime or use a consistent storage snapshot.

Permission denied

Reading a block device or writing to a protected destination commonly requires administrative privileges. Use sudo where appropriate, select a writable destination with adequate free space, and check whether security policy is blocking access.

The dump is expected to restore files

This is a misunderstanding of the metadata-only design. xfs_mdrestore creates a structural analysis image; it does not recover ordinary file contents. Use a verified backup or a dedicated data-recovery procedure when file data is required.

Summary

Use dumpe2fs with an ext2, ext3, or ext4 block device. Add -h for a concise superblock and header report.
Use xfs_info with a mounted XFS mount point to inspect geometry, allocation groups, inode and directory settings, log configuration, naming, and features.
Use xfs_metadump to create a separate XFS metadata diagnostic dump from an unmounted or read-only-mounted source.
Use xfs_mdrestore to create a metadata-only analysis image, not a file-data backup.
Always verify the device, type, mount state, permissions, destination space, and sensitivity of diagnostic output before collecting information.