A file system is a way of storing and accessing data on media. The result is the data itself plus some metadata, which contains additional information about the data – including dates and times, access permissions, and more.

Theoretically, the same user data could be accessed from two different files. This is done through symbolic links and will be the topic for another blog post. The file systems must be careful to control access, as both writing and deleting operations can affect anyone using that data.

OverlayFS: understanding data integrity in Linux

On Linux, there is another way to get at the data, a method of access through a fully separate file system. This service is referred to as a union file system, a file system on a union mount, and the most widely used of those is detailed below.

Enter OverlayFS! Brought into the Linux kernel mainline with version 3.18, it allows you to overlay the contents – both files and folders – of one file system onto another.

How does OverlayFS work?

On Linux, each file system is attached to a system directory: the mount point. OverlayFS allows two mounted directories – which can be on different volumes and different file systems – to provide access to the same file and folder structure. One famous example is overlaying a standard file system like ext4 over the file system of a read-only CD-ROM. This allows temporary modification of those read-only files.

One of the best ways to understand how OverlayFS works is by picturing it in action. The image below shows a simple example of two file systems, each containing files and folders. We can think of them as “upper” and “lower” file systems. OverlayFS provides a fusion of the files from those two file systems. Linux applications use OverlayFS to access data – it will retrieve a file from the “upper” file system first, then default to the “lower” file system if that file doesn’t exist.

It’s important to note that the two original file system directories (“upper” and “lower”) are still directly accessible to a Linux kernel, but this access could be limited by the application.

Any modifications to a file or folder in the “upper” file system directory will take place as usual. Any modification to a file or folder whose data comes from the “lower” file system directory will create a copy in the OverlayFS file system, and that file will be the one modified. This leaves the base file or folder untouched and still available through direct access to the “lower” file system. The observant among you have noticed this seamlessly provides “copy-on-write” method for any file system, not just OverlayFS.­­

Exploring whiteout and opaque directories in OverlayFS

A file removed from the OverlayFS file system would directly remove that file from the “upper” file system and simulate that removal from the “lower” file system by creating what is called a “whiteout” file. This file exists only within the OverlayFS directory, without physically appearing in either the “upper” or “lower” directories.

A subdirectory can also be deleted from the “lower” directory, which creates what is known as an “opaque directory” in the OverlayFS directory. Behind the scenes, OverlayFS uses the “trusted” extended attribute class or namespace to record “whiteouts” and “opaque directories.” Linux file systems that support the “trusted” namespace can be used for either directory. Tuxera file systems available on Linux support this feature, along with recent enhancements made to “whiteout”.

Other recent kernel changes include adding ID mapping to OverlayFS in kernel 5.19, and support for fsverity was added in kernel 6.6.

Transaction points in OverlayFS

When the OverlayFS is dismounted, all state information in the OverlayFS file system is lost. Changes to the “upper” file system, including whiteout and opaque directories, are also lost. Care should be taken to reflect any necessary changes in the standard kernel mount point of the “lower” file system, or to another target file system as appropriate.

Interestingly, both the copy-on-write nature of OverlayFS and a periodic operation storing the modified state of the “upper” folder into the lower could be used to add predictable data integrity to a Linux file system. These are the two actions used to create a transaction point.

Tuxera Reliance Nitro and OverlayFS

For an embedded system, power loss is always a risk. OverlayFS is an interesting way to improve data integrity, but in embedded systems, we recommend using Reliance Nitro to provide data integrity in a more predictable way.

A union file system like OverlayFS can provide developers with a way to effectively make modifications to read-only media, without actually altering what is written onto the media itself. This same technique could be used to refine a target file system in a controlled way or perform system updates. The added data integrity can improve many use cases in Linux.

Tuxera file systems like Reliance Nitro provide full support for OverlayFS in any use case. For an embedded design, Reliance Nitro provides data integrity through Dynamic Transaction Points, without the overhead of OverlayFS.