As one of the core components of the general distributed file system FastCFS, FastDIR is a high-performance, large-capacity distributed directory service. In addition to supporting the basic features of the file system, it also implements the following features:
* Supports all types : such as sockets, character devices , symbolic links, etc., and also supports hard links ;
* File lock : fully supports POSIX file lock, supports adding/unlocking by range;
* File extended attribute (x-attribute) , V2.0 began to support, used to save storage pool related attributes .
FastDIR supports namespaces. One namespace corresponds to a set of directory structures. The directory structures of multiple namespaces are independent of each other, and different applications can be isolated through namespaces. FastCFS V2.0 began to support storage pools, and a storage pool corresponds to a namespace of FastDIR.
If the traditional locking method is used to modify and access the directory structure, there will be a performance bottleneck due to the large granularity of the lock. FastDIR introduces data threads, a data thread manages multiple namespaces (directory structures), and data threads access the directory structure under its jurisdiction in a lock-free manner. In order to give full play to the capabilities of multi-core CPUs, multiple data threads can be configured. FastDIR is routed to data threads by namespace, and the directory structure under a namespace is processed by only one data thread, so no locks are required.
FastDIR uses a skiplist to store the directory structure in memory, which is simple and efficient. The jump table is provided by the basic library libfastcommon, and the memory allocation of the jump table and its nodes uses the object pool. According to the actual measurement that an inode occupies about 270 bytes of memory, it is estimated that 64GB of memory can store 200 million inodes (Note: the memory usage is calculated at 80%).
FastDIR uses binlog for data replication within the cluster. Binlog is also an implementation of data persistence. When the program starts, all data is loaded into memory through binlog replay. V3.0 implements data persistence through storage plug-ins, loads data on demand, and cooperates with the LRU elimination algorithm to support tens of billions of massive files with limited memory (such as 64GB) on a single machine.
The storage plug-in uses the combination of inode persistent data and the original binlog to asynchronously place the modified inode data on the disk, which is simple and efficient. Data placement must meet one of the following two conditions:
* The number of modified inodes reaches the threshold, such as 102400;
* The time interval is exceeded, such as 60 seconds.
The LRU elimination algorithm of FastDIR storage plug-in has the following two characteristics:
* Elimination by directory structure: Eliminate child nodes first, and then eliminate parent nodes;
* Elimination by data thread: Each data thread is an independent data unit, and data storage Both fetches and evictions are done lock-free in its data thread.
Friendly reminder :
* FastDIR is a general-purpose distributed directory service, which can be deployed separately to store directory structures in other scenarios;
* If the number of files is only tens of millions, you do not need to enable the storage plug-in;
* It is recommended to enable the storage plug-in in the production environment Use SSD, NVMe SSD is recommended.
The FastDIR storage plug-in can be turned on and off at any time. Please download and use the latest version V3.1 from the FastCFS project official website. If you have any questions or suggestions, please feel free to give feedback and exchange.
Attach the FastCFS project address: https://gitee.com/fastdfs100/FastCFS