File systems of BSD, Solaris, Unix

As pointed out in the article on Filesystems basics, a filesystem constitutes an indispensable part of any OS. And most operating systems tend to employ their own native FS formats, whose support may be limited or unavailable under other environments. Speaking of the Unix family, this OS and its variants, like BSD and Solaris, have traditionally relied on UFS, which was later upgraded to UFS2. After a while, a next-generation filesystem called ZFS originated from Solaris. The latter has also gained immense popularity and promptly made it to other platforms. Here you can find a brief overview of these two most common FS types, learn about their key peculiarities and storage technologies associated with them.

Please note: Some of these operating systems may provide read-write support for other formats, such as FAT/FAT32 of Microsoft Windows and Ex2/Ext3/Ext3 of Linux, that are described in the respective articles.

Content:

UFS/UFS2

UFS (UNIX File System) stems from the Berkeley Fast File System (FFS), which was developed by the Computer Science Research Group (CSRG) from the University of California, Berkeley and released in 1983 along with the 4.2 BSD UNIX distribution. The work on UFS continued and, eventually, it became the primary format for machines running BSD and other derivates of Unix. Presently, despite being rather old-fashioned in terms of features, UFS remains the filesystem of choice in view of its highly stable performance.

The storage space in UFS is divided into Cylinder Groups. Their locations and other important service information can be found in the Superblock. A file in UFS is represented by an individual descriptor referred to as an inode, along with data blocks that make up its content. Each Cylinder group keeps track of its free blocks and inodes using dedicated bitmaps.

An inode has all of the file’s attributes, except its name. It also stores the direct addresses of its first 12 data blocks. If there are more blocks, the subsequent addresses point to indirect blocks that store direct block addresses. A directory, on the other hand, consists of entries that associate the inode numbers with the names of the files residing in the given directory.

Though UFS creates a single inode for each file, it allows storing the same file in multiple directories and under different names. Such files share the same inode and are known as hard links. In this case, the inode will indicate the precise number of references to it.

Over the years, UFS has gone through many changes. In 2003, UFS2 was introduced as a replacement to the original UFS, extended for deployment on multiterabyte storage devices. Moreover, many Unix vendors created their own adaptations of UFS. For instance, Sun Microsystems added journaling to their version of UFS in Solaris 7. This filesystem records all metadata updates in a log before applying them to any actual structures, thus ensuring its protection against crashes that may happen in the process.

As a result, considerable differences may exist between distinct UFS implementations. That being so, the entire filesystem family is known as UFS, but many of its instances may be adapted to particular uses or have proprietary extensions that are incompatible with the counterpart Unix variants.

ZFS

ZFS (Zettabyte File System) was created in 2001 by Sun Microsystems as a part of their Solaris OS. In 2005, it was made open-source and integrated into other platforms, including BSD. When Oracle Corporation acquired Sun in 2010, further development of ZFS became proprietary. For that reason, a separate project called OpenZFS was established, which made it possible to maintain the open-source ZFS code base and keep it available to the public outside the closed Oracle’s ecosystem. Still, ZFS couldn’t be included directly into the Linux kernel due to a licensing conflict, and the ZFSonLinux (ZoL) initiative was launched to address this problem. All this resulted in the existence of several distinct "branches" of ZFS.

As a whole, ZFS has radically changed the idea of what a filesystem is. It offers native volume management capabilities, similar to those provided by RAID-based technologies, along with many other unique features.

ZFS can incorporate multiple storage media. Their resources are combined into a singe shared pool of storage. It may contain one or more virtual devices referred to as vdevs. Each vdev is described by an individual label, which also holds its Uberblock. The latter has functions similar to those of the Superblock in other filesystems.

Storage allocation is performed in blocks of variable sizes. These blocks are organized as objects of different types, like file objects and directory objects. A special structure called a dnode records the object type, size and points to blocks that store its data content. There can be up to three block pointers in a dnode. Such a pointer can refer either to a leaf block that stores actual data or to an indirect block which, in its turn, points to another block.

Similar objects are grouped together, forming object sets. Each object in such a set can be identified by its number. The collection of dnodes describing them are also stored as an object pointed to by a special dnode called a metadnode. A dedicated object set called the Meta Object Set keeps the metadata that characterizes the entire storage pool.

ZFS also employs the Copy-on-Write (CoW) mechanism. It always creates a copy of the block to be modified, instead of replacing it directly. Once the operation is completed, the block pointer is updated to indicate the address of the newly written block, whereas the original version remains unchanged.

Presently, ZFS is extensively deployed by enterprises and tech-savvy individuals. Though there are some discussions concerning its current stability, this format has a vast potential to become the new go-to option.

Hint: The information about the likelihood of a successful result when it comes to data recovery from these FS types can be found in the articles about OS-specific peculiarities of data recovery and chances for data recovery. The process itself is described in the instruction dedicated to data recovery from Unix, Solaris and BSD.

Other storage technologies of the Unix OS family

UFS/UFS2 is a traditional file system fitting more for rather simple use cases. While self-contained in terms of basic FS functionality, it doesn’t include any advanced storage management features and has to rely on kernel-level frameworks or external utilities to handle more complicated tasks, like RAID or encryption. In contrast, ZFS is a next-generation format that combines a file system and various volume management mechanisms into a single package, eliminating the need for external tools.

Below are some common storage technologies that may complement these file systems:

  • GEOM Framework – a modular storage framework that can be used in conjunction with UFS/UFS2 in the FreeBSD operating system, allowing for advanced configurations with the storage devices on which this file system resides. GEOM abstracts them into virtual "providers" that can be used by the file system. Such a provider can be represented by a single drive, multiple drives organized into RAID 0 (striping) or RAID 1 (mirroring), or an encrypted volume.

  • zPool – a core storage construct in ZFS that aggregates multiple devices into a single logical storage unit, leveraging the native pooling capabilities of this file system. In such a pool, the data can be spread across the drives without redundancy (similar to RAID 0), mirrored across two or more drives (similar to RAID 1) or organized as RAID-Z, a more advanced setup described below.

    Hint: Please rely on the instruction if you need to recover data from a simple ZFS volume (striped or mirrored).

  • RAID-Z – RAID-like functionality built into the ZFS file system to enhance storage efficiency and provide fault tolerance. The data within the pool is divided into chunks that are written across multiple disks, with one or more parity blocks calculated for the data in those chunks. Depending on the chosen configuration, the array can use a single parity block to protect against the failure of one drive (RAID-Z1), two parity blocks to withstand the failure of two drives (RAID-Z2), or three parity blocks to allow for the failure of three drives (RAID-Z3).

    Hint: Please rely on the instruction if you need to recover data from ZFS RAID-Z.

  • ZFS encryption – an encryption feature integrated into the ZFS file system. It makes it possible to encrypt each dataset within a ZFS pool independently, ensuring security for specific portions of the stored data.

Should you wish to learn about the filesystems typical for other environments, please read the following articles:

Last update: November 14, 2024

If you liked this article, you can share it on social media: