# A Lightweight File System Design for Unikernel
## 3 Design Issues of Unikernel File Systems  
### Classification of Unikernel File Systems  
Unikernel file systems can be classified into three types, as shown in Figure 1, depending on the storage interconnection method. The first is a type of in-memory file system in which all data in the file system is managed within the Unikernel without host intervention. File systems in this category have the advantage of providing performance comparable to general-purpose operating systems. Also, there is a merit to security as all file system data are hidden on the host and managed by the Unikernel. However, as in-memory file systems do not have persistency features (i.e., their contents will not be retained when the power is turned off), applications need to back up file system contents through additional I/O or network operations explicitly to preserve data. Therefore, file systems in this category are mainly used for maintaining temporary files, which are necessary only when the Unikernel is activated. This type of file system also has the drawback of large memory consumption for the file system, which is not desirable for Unikernels that aim at being lightweight.  
\begin{table}
\begin{tabular}{p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt}} \hline \hline
**File System** & **Target Project** & **Design Style** & **Need for Hypervisor** & **Implementation Approach** & **Limitations** \\ \hline \multirow{3}{*}{Rumpvfs} & Nabla (2018) & In-memory file system & No & Imported from Rump kernel without custom development & - Low performance due to adopting general purpose file system - No persistent storage \\ \hline \multirow{3}{*}{Rams} & Unikraft (2021) & In-memory file system & Yes & Developed with Unikernel in mind but encompass too many features & - High memory requirement - No persistent storage \\ \hline \multirow{3}{*}{9 pfs} & Unikraft (2021) & Host-based file system & Yes & Imported from Qemu without custom development & - Low performance due to frequent hypercalls - Low security due to direct exposure to host \\ \hline \multirow{3}{*}{Hcfs} & hermitux (2019) & Host-based file system & Yes & Redirect guest file system API requests to host & - Overhead of API request redirection - No isolation guaranteed as all file operations performed at host \\ \hline \multirow{3}{*}{ULFS} & ULV (2022) & Hybrid file system & No & Developed from scratch with streamlined design & - Unfit for large scalable workload \\ \hline \hline \end{tabular}
\end{table}
Table 1: Comparison of ULFS with existing Unikernel file systems.  
The second type is a host-based file system that maps files in the Unikernel file system to files on the host or forwards API requests from the Unikernel file system to the host. In this type, file system storage is entirely dependent on the host side. Unlike in-memory file system types, applications that use these file system types can utilize the file system for persistent data 1/O. Also, the memory space consumed by this file system type is less than that of the in-memory file system type. However, hypercall operations for this file system type become complicated as the Unikernel's file system needs to communicate with the host file system for each file operation. There is also a security problem such that files used by guests are visible to the host. Moreover, although the memory consumption of the file system is less than that of the in-memory file system, in general, it is difficult to control the memory usage of the host file system, possibly leading to increased memory usage.  
The third type of file system makes use of a hybrid approach where the host provides a dedicated storage device to the Unikernel, and the Unikernel performs file services by making use of the storage on the host. Unlike the host-based file system type, a block device-level interface is used for this type, so hypercall operations between the host and Unikernel can be simplified. Also, it has the advantage of minimizing the vulnerability of guest file data being exposed to the host.