coat of arms of Ukraine We are Ukrainians, and we are proud of it! How can you support Ukraine in this hard time?

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 and learn about their key peculiarities.

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.

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

Last update: April 20, 2023

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