## 5 System Overview
### Virtual File System  
The system creates a file that occupies 80% of the total free space on the physical device. At this point, as shown in Figure 3, the file will form a continuous area on the physical drive. Thus, the required disk I/O will decrease. This file is divided into blocks called a bunch of 10 MB Figure 5 shows a bunch structure. A bunch consists of 3 bytes of next bunch information, 1 byte of data indicating to which replica server is kept, 4 bytes of client application IP, and 50 bytes of the file name and data block. The bunches behave exactly like an array, and the index number starts from zero. As shown in Figure 6, the disc header consists of 3 bytes of data holding the amount of bunch and 200 KB of data in bitmap  
Figure 4: File storage processing.  
format. Whether each bunch is empty or not is controlled by the bitmap structure, in which each bunch is represented by one bit and '1' represents used or reserved bunch otherwise the bunch is empty, which means it is ready to be used in the file chain. This bitmap field size is 200 KB. Thus, a storage area of 16 TB is reached. Each bunch holds a 3-byte pointer that holds the next bunch in itself. Files that are bigger than a bunch size are kept in the file chain. As shown Figure 7, each bunch points to the next data block with of 3 bytes next pointer. The pointer holds the index of the next bunch. If this pointer is '0', it means that the bunch represents EOF, in other words, this bunch is the last one of the file chain. Data nodes are responsible for storing, reading, deleting, and backing up the files sent to them. One of the most basic features of this structure is that the starting bunch number of the file stored in the nodes is sent with the file name and in this way/thus the reading starts with one disk access. With this feature, system performance is quite satisfactory. This situation is shown in Table 2. The result of comparing the performance values of KUSDFS with other systems is shown in the diagram in Figure 8.  
Figure 5: Bunch structure of file system.  
Figure 6: Structure of disc header.  
Figure 7: Structure of file data bunch.  
Firstly, the developed system can be used by more than one client application server. The client application server is matched to one of the data nodes, and all requests are forwarded to this server (data node). A data node can serve multiple client servers; this increases the survivability of the system. Application servers may communicate with different data nodes, and this definitely will not affect the operation of their systems. Each of the data nodes in the system can serve multiple client servers at the same time. In short, all nodes of the system can be used as a server when requested. With this feature, survivability, availability, and reliability values give very good results.  
The client application works with the data node to which it is connected, when the client-server wants to store the file, requests the address of the next data node from data node. The client-server that receives this address writes the file to the data node at this IP address. The application server writes its files in order to the data node in the system. The only task of the data node that the application is associated with is to give it an IP address. In fact, this structure resembles the name node in the Hadoop architecture.