fedir/ICFS-thesis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updated evaluation

Browse Source
This commit is contained in:
fedir 2025-05-16 19:00:55 +02:00
parent 607a2171c6
commit d11fe72194
Signed by: fedir
GPG Key ID: C959EE85F0C9362C
2 changed files with 11 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
evaluation.tex
View File

@ -12,11 +12,9 @@ We tried to asses the quality of ICFS by the following metrics:
\section{Test environment} \section{Test environment}
For performance and usability tests, we used an HP Pavilion Laptop 15-cc563st with an Intel® Core™ i7-7500U processor, a Western Digital WDS250G2B0B WD Blue 3D NAND internal M.2 SATA SSD and 12 GB of DDR4 RAM, running Fedora Linux 42 (Workstation Edition) with Linux 6.14.5-300.fc42.x86\_64 kernel, GNOME 48 desktop environment with Wayland window session. Performance and usability evaluations were conducted on an HP Pavilion Laptop 15-cc563st equipped with an Intel® Core™ i7-7500U processor, a Western Digital WDS250G2B0B WD Blue 3D NAND M.2 SATA SSD (250GB), and 12 GB of DDR4 RAM. The system ran Fedora Linux 42 (Workstation Edition) with kernel version 6.14.5-300.fc42.x86\_64 and GNOME 48 under the Wayland session. For additional compatibility testing, a KVM virtual machine hosted on the same hardware emulated a Debian GNU/Linux 12 (bookworm) environment with kernel 6.1.0-27-amd64, GNOME 43.9, and the X11 windowing system. The virtual machine had 2 CPU cores and 2 GB of RAM.
For additional compatibility tests, a KVM virtual machine running on the same laptop was used. The OS on the virtual machine was Debian GNU/Linux 12 (bookworm) x86\_64 with 6.1.0-27-amd64 kernel, GNOME 43.9 with X11 windowing system. The virtual machine was given 2 CPU cores and 2 GB of RAM. To simulate real-world usage, ICFS was mounted to a directory pre-populated with files, and interactions were tested across six widely used applications:
To assess the qualities of ICFS during regular usage, we have mounted it to a directory pre-filled with files, and attempted to access the files with different software. While trying to simulate common use-case scenarios, we tested the following programs' compatibility and usability with ICFS:
\begin{itemize} \begin{itemize}
\item {\TeX}studio. \item {\TeX}studio.
@ -27,7 +25,7 @@ To assess the qualities of ICFS during regular usage, we have mounted it to a di
\item Standard command line core utilities (e.g. \verb|ls|, \verb|cd|, \verb|grep|, ...). \item Standard command line core utilities (e.g. \verb|ls|, \verb|cd|, \verb|grep|, ...).
\end{itemize} \end{itemize}
We chose these programs not only because of their commonality, but also since they exhibit fairly diverse patterns of filesystem usage that are relevant in practice. These tools were selected for their prevalence and diverse filesystem interaction patterns. Except for Syncthing and Firefox (distributed via Flatpak containers), all applications were installed as native packages.
\iffalse \iffalse
@ -43,11 +41,9 @@ For performance testing, special scripts were written, that test the speed of `o
\section{Usability} \section{Usability}
While it is difficult to put an objective score on the ease of use of any system, we measure the usability of ICFS by the amount of dialogues the user has to consciously react to while using the system. Testing revealed that most applications interacted smoothly with ICFS. TeXstudio and Neovim required a single permission prompt when opening existing projects, with no further interruptions for new file creation.
In our testing we found that most programs' filesystem usage was quite manageable with ICFS. {\TeX}studio and Neovim only required the user to interact with a single dialogue when opening existing projects, and none when creating new files. GNOME Files (Nautilus) exhibited unexpected behaviour. While functional without access permissions, its thumbnail generation process triggered repeated prompts. The file manager employs an external utility, gdk-pixbuf-thumbnailer, to create previews of files such as images.
The file manager Nautilus generally did not require any access permissions to function, but generated more dialogues than initially expected. When started, Nautilus opened files to scan them to display mini-previews of their contents.
\begin{figure}[H] \begin{figure}[H]
\centering \centering
@ -55,24 +51,19 @@ The file manager Nautilus generally did not require any access permissions to fu
\caption{Example of a picture mini-preview: image on the left is the scaled-down version of the actual image stored in the file.} \caption{Example of a picture mini-preview: image on the left is the scaled-down version of the actual image stored in the file.}
\end{figure} \end{figure}
So, for every image to be scanned, a permission was required. It might seem like a simple problem to solve at first: after all if the user gives even a temporary permission to the entire folder, all images should open seamlessly. The issue is, that Nautilus uses another program (gdk-pixbuf-thumbnailer) to scan images on its behalf, one image at a time. Hence, every temporary permission given to that program, will only last until the next image is opened. One practical solution to this problem is to give gdk-pixbuf-thumbnailer a permanent permission to access the folder in question. Each preview required individual authorisation because the thumbnailer operates per-file, invalidating temporary folder permissions after each new image access. A pragmatic solution involves granting permanent access to the thumbnailer for specific directories -- a trade-off between convenience and security.
The web browser used the filesystem only when a file was downloaded and consequently needed saving. To select the path for the file, web browsers use file selection dialogues provided by the system file manager. Firefox interactions were limited to file downloads and uploads, which utilise system-level file selection dialogs managed by the system file manager.
\begin{figure}[H] \begin{figure}[H]
\centering \centering
\includegraphics[width=0.6\linewidth]{./images/file-selection-dialogue.png}
\includegraphics[width=\linewidth]{./images/file-selection-dialogue.png} \caption{File selection dialogue in Firefox.}
\caption{}
\end{figure} \end{figure}
This is mostly solved in my experience. It wasn't as annoying to use the terminal programs as I initially expected. Hence, it inherited all issues Nautilus had. However, denying Nautilus permissions did not disrupt the download process itself, and ensured users could selectively authorise only the target save location -- a critical safeguard for internet-facing applications.
As for terminal programs, I see these possible \sout{solutions} improvements: Containerisation significantly impacted Syncthing ’s usability. Flatpak-packaged applications often modify filesystem paths visible within their sandbox. In Syncthing’s case, the executable’s relocated path invalidated \verb|/proc/pid/exe| -- a symbolic link in Linux’s procfs filesystem that typically points to a process’s binary. ICFS relies on this link to verify process identities for persistent permissions.
\begin{itemize}
\item Use SID and TTY to identify a shell session (like \verb|sudo| does).
\end{itemize}
\section{Performance} \section{Performance}

BIN
main-en.pdf
View File

Binary file not shown.