# Evaluation of a New-Concept Secure File Server Solution
## 5 Discussion  
Considering the reading test results of the reference-based performance evaluation, the proposed solution outperformed the performance of the Windows 2019 Server in most cases and resulted in only a few cases of similar or slightly slower performance. The methods for increasing reading speed are well-documented in the relevant literature. In particular, server-side service parameters need to be fine-tuned or defined depending on the specific client operating systems. In the writing tests, the proposed solution performed mostly worse than the Windows server. This is mainly due to two important factors that caused considerable workload in the FreeBSD-based environment. One is the file system-level encryption to prevent physical data theft, and the other is volume-based automatic snapshotting, which only imposes a significant challenge when writing data. Integrating these two services, of course, was a handicap compared to the Microsoft system, but since most live Windows servers do not have file encryption (BitLocker) enabled by default and shadow copy (VSS) is only enabled on the system partition, we wanted the analysis to be based on a typical user practice. To widely deploy the proposed solution, it is important to ensure that services such as scheduled snapshotting, honeypot network drive monitoring, IDS/IPS, virus protection (real-time or scheduled virus scanning depending on hardware capacity), the automated backup system, or AI-based log monitoring should not result in significant performance degradation compared to the commonly used solutions. The results show that while only minimal parameter correction is needed for performing read operations efficiently, significant speed-ups are essential for write operations. For this purpose, the following \"best practice\" solutions can help: client-specific configuration fine-tuning on the server side, increasing the buffer size, adjusting caching parameters, using an extra SSD for caching, and client-side optimization (registry, GPO, and SMB parameters). Our answer to the first research question (RQ-1) is a definitive yes. At the current configuration level, the evaluation of the measurement results confirms that the proposed system does not lag behind the file servers operating on traditional platforms in terms of measurable performance parameters. The conducted study was able to partially answer the second research question (RQ-2): whether the performance of systems set up with different default service environments can be compared. In order to detect truly significant differences in performance, further studies are required in environments built with coordinated services. \begin{table}
\begin{tabular}{l c c c c} \hline \hline  & \multicolumn{4}{c}{**Files**} \\  & **1 \(\times\) 1 GiB** & **4 \(\times\) 256 MiB** & **256 \(\times\) 4 MiB** & **2097 \(\times\) 500 kiB** \\ \hline \multicolumn{4}{l}{**Reading test results**} \\ \hline Windows 10—ARDS TestServer/ & & & & \\ Windows 10—Windows 2019 Server & 0.7809 (\({}^{+}\)) & 0.8672 (\({}^{+}\)) & 1.2733 (\({}^{-}\)) & 1.0728 (\({}^{=}\)) \\ \hline Ubuntu 22.04—ARDS TestServer/ & & & & \\ Ubuntu 22.04—Windows 2019 Server & 0.6134 (\({}^{+}\)) & 0.6199 (\({}^{+}\)) & 0.4947 (\({}^{+}\)) & 0.7620(\({}^{+}\)) \\ \hline \multicolumn{4}{l}{**Writing test results**} \\ \hline Windows 10—ARDS TestServer/ & & & & \\ Windows 10—Windows 2019 Server & 3.0263 (\({}^{-}\)) & 3.2113 (\({}^{-}\)) & 1.2903 (\({}^{-}\)) & 0.7893 (\({}^{+}\)) \\ \hline Ubuntu 22.04—ARDS TestServer/ & & & & \\ Ubuntu 22.04—Windows 2019 Server & 2.8602 (\({}^{-}\)) & 2.7480 (\({}^{-}\)) & 2.4110 (\({}^{-}\)) & 2.1825 (\({}^{-}\)) \\ \hline \hline \end{tabular} \({}^{(+)}\) ARDS TestServer performed better. \({}^{(-)}\) Windows 2019 Server performed better, but the difference in speed was under 10 percent. \({}^{(-)}\) Windows 2019 Server performed better, and the difference in speed was higher than 10 percent.  
\end{table} 
Table 7: Reference-based performance evaluation for reading and writing tests on 10 Gbit/s bandwidth.