## 3 Design of a Lightweight Distributed File System Based on RDMA Communication Mode
### FastDFS Communication Process Optimization Scheme Based on RDMA  
In the discussion of the asymmetry of unilateral RDMA communication, it can be found that the server's active RDMA IOPS has become the server's bottleneck, its passive RDMA operation is far from saturated, and the resource utilization is not high. Therefore, if you change its communication flow and change the active RDMA operation on the server side to a passive RDMA operation (that is, the Client initiates the RDMA request), you can further improve the performance of the distributed file system proposed in Section 3.1. In this section, we detail the main process of optimized file upload and file download, and propose and solve problems that may arise from other modification processes. (1) Main process logic  
The following describes the optimized FastDFS communication process, in which the critical active RDMA operation steps on the server side are changed to passive. 1. Optimized upload process  
As shown in Figure 5, the optimized file upload process is as follows (the circle marked by the red line is the modified process). 2. Optimized download process  
Similar to the upload, Figure 6 illustrates the optimized download process. Figure 5: The optimized file upload process. (2) Determination of relevant parameters  
In the design described above, a critical problem needs to be solved. Since the client needs to initiate an active RDMA operation with the server to obtain the result after starting the upload request or download request, the server does not actively respond. At this time, the client will face two problems:  
1. Determining when to obtain results from the server;
2. Determining the size of the result obtained from the server at a time. For the first problem, the easiest way is to let the Client repeatedly retry. RDMA Read obtains the result from the response buffer of the server. Similarly, on the server side, the server side constantly checks whether there are new requests in the request buffer. However, this method has a clear disadvantage, that is, it wastes the Client's CPU cycles, especially when the number of retries is too high, making its CPU too high, and also wastes the server's passive processing of IOPS. Therefore, one should try to set a threshold \(T\), and when the retry time is greater than \(T\), it is considered to be a timeout, and the connection is disconnected. The setting of the threshold \(T\) must be reasonable. It must not be too small, otherwise, the link may be disconnected before the tracker is ready for data, and \(T\) must not be too large, otherwise, it will consume too much Client CPU and reduce throughput. To achieve a better result, the value of the threshold \(T\) must be determined. \(T\) has the following relationship with throughput \(TH\):  
\[TH=argmax\,f(T,F,P,S)\]  
In the formula, \(T\) represents the time of the attempt to read the RDMA from the Client before disconnecting, \(F\) stands for the extract size that the Client uses to read remote results from the server, \(P\) represents the processing time of the request on the server, and \(S\) represents the size of the result after the server has processed it. The solution to the first problem is to conduct multiple experiments. First, record the average processing time of the server, then refer to the processing time, and temporarily set \(T\) to a rough guarantee that the Client can correctly retrieve the value of the result \(Tmax\). Then, conduct multiple experiments using the idea of dichotomy. Set the value of T one by one, and look for the lowest possible time from the experimental results that can fully guarantee that the results are retrieved correctly. However, regardless of the number of T settings, the client may fail at a certain fetch of results, which requires an error-handling mechanism. The system sets that, when the correct result is not obtained, a retry  
Figure 6: Optimized download process.