XFS Data Volume

XFS development was started in 1993 by Silicon Graphics Inc. and released the following year on their IRIX operating system. It is a high performance 64-bit journaling file system, excelling in parallel input/output operations. The maximum supported data volume size is 16EB and a maximum file size of 8EB.

In 2000 XFS was released under the GNU General Public License (GPL) and ported for the Linux operating system, and released the following year. In 2014 Redhat Linux started using XFS as the default file system, including support as the boot partition. The specifications have been released, the details of which can be utilised for the purposes of XFS data recovery, to overcome a variety of file system problems.

Features of XFS Data Volumes

As is now common, XFS uses journaling to enable the recovery of all system metadata following a crash or power failure. XFS introduced 64 bit date times extending the Unix date range beyond 2038, along with nanosecond resolution, rather than the traditional 1 second resolution of UFS.

A unique feature of XFS is the pre-allocation of I/O bandwidth at a pre-determined rate. This is suitable for many real-time applications. This feature is however, only supported on IRIX using specialised hardware.

XFS Data Volume Internals

XFS splits the file system into Allocation Groups (AG) with no pre-defined inodes allocated. All inodes are dynamically allocated, and referenced according to their AG and position within it. The only pre-allocated system structures are the superblocks, a copy in each AG, and the data block usage bitmaps. This avoids wasting space for a file system containing only a small number of files, but conversely does not place an arbitrary limitation on the number of files and directories allowed.

Directories are stored using a BTree, which allows fast and efficient searching and sorting. Files allocation uses extents, these also stored in a BTree, which allows for fast access of any data block; very useful for real time systems.

XFS Data Recovery

While XFS is fairly complex, the specifications are readily available, making the development of data recovery tools relatively simple. The most common reasons for XFS data recovery are due to hardware failure, deletion of the partition, or reformatting the volume.

The metadata structures, allow the file system to be readily scanned during data recovery for lost files and directories, following the loss of important sections of the file system.

When an XFS volume is formatted, only the initial inode allocation (usually 128 entries) including the root directory is overwritten, along with the data block usage bitmaps. This allows data recovery to be performed upon a data volume which has been reformatted, with only minimal data loss, depending upon the amount of data written after the format procedure.

Linux Extended File System

The extended file system, ext was created in April 1992 specifically as the first file system for use by the Linux kernel. The metadata structures are very similar to the traditional Unix File System (UFS) allowing a data volume up to 2GB in size.

In January 1993 this was replaced by the second incarnation of the file system, ext2. Depending upon the implementation in the Linux kernel, the maximum volume size can be from 2TB up to 32TB. The largest filesize is correspondingly between 16GB up to 2TB. Despite the introduction of ext3 and ext4 versions, ext2 is still being used, although mostly on SD cards and USB flash drives. Information about all versions of the file system is readily available, via the open source community, and data recovery from most situations is possible.

Features of Linux Extended File System

Ext3 introduced journaling in 1991, to allow the automatic recovery of the file and directory metadata after a crash or power failure. Like UFS the allocation is block based, with indirect allocation blocks used for large files. A driver allowing data compression is available, but in practice rarely ever used.

Ext4 was developed in 2008, which extended the maximum volume size to 1EB and the maximum file size to 16TB. The date time which can be specified was also enhanced allowing a much wider date range, as well as nanosecond resolution, rather than 1 second resolution.

Linux Extended File System Internals

The internal structure is very similar to UFS, with inodes and usage bitmaps allocated in fixed positions for each cylinder group. Ext3 saw HTree indexing added for large directories, to improve the performance of the file system, when a large number of files or directories are stored together.

Extents were added with Ext4, allowing a set of contiguous blocks to be defined efficiently, in chunks of up to 128MB. Up to four extents can be defined in the inode, with an HTree used to store the remaining allocation. The number of subdirectories allowed was also increased from 32,000 to an unlimited number.

Linux Extended File System Data Recovery

As with UFS, data recovery from ext2, ext3 and ext4 file systems is a relatively well known process, with no surprises. These file systems also suffer the same problem that the loss of directory index information, will lose the name of the file or directory associated with an inode. A reformat will also see all inodes overwritten, resulting in the loss all metadata. A data trawl in such a situation is the only data recovery option left.

If the extended file system can’t be automatically repaired and mounted by the operating system, it is important not to run third party tools in an attempt to fix the issue, as they may destroy important data structures. Once the operating system is unable to mount the file system, severe damage has occurred, which requires a professional data recovery service to examine the data, as a full understanding of the underlying data structures is necessary.