1. -A File System for Lots of Tiny Files
yyfs
-A File System for Lots of Tiny Files
Yi Jun, Yuzhe Liu
11/17/2018

2. Motivation Motivating Applications
user tend to use the file file in a unusual way
Generally, the workload that dominated by many tiny files references that have the batch processing characters
Motivating Applications:
Users tend to employ file system in a unusual way: …
Yyfs is tailored for workload consists of lots of tiny files that has the burst batch characteristics. Therefore, file reference locality may in each batch job can be taken advantaged of, if exists.
11/17/2018

3. Problems problems: tradeoffs between performance and space efficiency;
I-node allocation problem
Problems exist in current G-P file system to solve these problems
Problems exist in existing specially-tailored file system to solve these problems
The problem is usually solved not cleanly: by trading off between performance and disk space efficiency.
Another potential problem inherent with such workloads are: I-node allocation problem
Inode is a limited system resource, and # is determined when the file system is created, large number of tiny files can use up the inode resource.
Problems when using existing General purpose FS under such context:
No deliberate policy or mechanisms to deal with such workload. And the above problems all appear. Thus trade off are made between disk utilization and performance. For example: the most recent fs, ext3[1],
Problems when using existing specially-tailored FS under such context:
Some specially tailored file system can only partially solve the problem, or do it in a not efficient way, like ReiserFS[2]. E.g., ReiserFS solves the problem of the inode resource problem, and tailors for small files. It uses some similar concept with ours: like put multiple tiny files in one block. However, it actually uses the disguise inode, and such information can be returned by stat command.
Since the data of each tiny files are very small, We don’t think separating the metadata and the data and retrieving them separately under the batching context is efficient, and instead, we put them adjacently to each other, and retrieve them together if necessary to save IO. Also we don’t consider it worthwhile to use the inode or even the disguise inode structure, because of the tiny size of the data, removing the direct items and indirect items, etc. in ReiserFS.
11/17/2018

4. Goal to be achieved
Achieve both high disk space utilization and performance
Do not incur the I-node resource limitation problem
Without compromising the big file reference machnisms
We propose a new file FS, which is tailored for the application scenarios where there exist large number of tiny files references with the batching characteristic, and take advantage of the reference locality in them, if there exist any.
Yyfs aims to achieve both good performance and high disk apace efficiency, as well as avoiding the i-node resource limitation problem. As we will show, yyfs significantly outperforms ext3 FS in IO performance and disk space efficiency.
However, we need to mentioned that Yyfs can deal well with large files as well, by keeping the basic data structures and reference strategies for large file in modern FS. So large files are still referenced via Inode in a strategy that used in modern FS.
11/17/2018

5. Design
Figure 1. Layout of structured block
11/17/2018

6. Figure 2. Structure of directory entry
11/17/2018

7. Figure 3. Blocking compacting
11/17/2018

8. Figure 4. System implementation big picture
Red: already cached
Blue: read from the disk
11/17/2018
Figure 4. System implementation big picture

9. Evaluations Workloads metrics Simple workloads Complex workloads
Batch tiny file creation
Batch tiny file sequential read
Batch tiny file deletion
Complex workloads
Randomly read/delete files
Randomly batch read/delete file
metrics
Number of IO transfer
Disk space utilization
We define several kinds of simple workloads that characterized our interested application scenarios for our evaluation.
We also test the performance of yyfs using several complex workloads. The goal of such testing is to see when locality is not available, how well yyfs will perform.
Each simple workload unit consists of a batch of 1000 tiny files. When files are batch read or deleted. It is executed on a large file pool which consists of 1,000,000 tiny files.
Complex workloads are used:
Randomly select 500 tiny files from the file pool to read or delete. The 500 files may not necessarily continuous.
Randomly select 10 blocks tiny files which only contains about 50 files to read or delete. And the tiny files in the blocks are assumed to be consitnuous.
Metrics:1. Number of IO transfer: denoted by the number of IO requests to the hard-disk.
2. Disk space utilization: the amount of disk space used to store the interested files.
11/17/2018

10. Simple workload-batch file creation
disk space utilization of yyfs is at least 65 times better than ext3. For ext3, even if each tiny file is
of only 10 bytes, it occupies a 4KiB block. While in yyfs, tiny files are compacted into a single block as many as possible.
With each tiny file of 10 bytes in data, and 32 bytes in metadata, each block can accommodate approximately 100 tiny files, thus leading to great disk space efficiency.
It is noticed that total amount of disk traffic is slightly bigger than the sum of data of all the files. This is because of the metadata information of the tiny files included.
Figure 5. Batch file creation: disk efficiency
11/17/2018

11. Simple workload-batch file creation-cont.
the number of IO transfer in yyfs is at least 6 times better than ext3. As shown, the advantage
of yyfs over ext3 in number of IO is less than that in disk space utilization. This is partially because in yyfs, each update in a structured data block requires additional update in the corresponding directory block that its container directory entry resides in.
However, the significantly better performance we achieved in yyfs is still rather conservative. In ext3, several logical IO requests are combined into a single IO request to the harddisk. Though our evaluation, the average value of this number is estimated to be 8-10, While in yyfs, no such optimization is employed. That is, this figure actually shows the worst-case performance of yyfs compared to ext3.
Figure 6. Batch file creation: number of IO
11/17/2018

12. Simple workload-Batch file read
Figure 7. Batch file read: number of IO
11/17/2018

13. Simple workload-Batch file deletion
Figure 8. Batch file delete: disk space efficiency
11/17/2018

14. Simple workload-Batch file deletion cont.
Figure 9. Batch file delete: number of IO
11/17/2018

15. Complex workload
Figure 10. Randomly read/delete files
11/17/2018

16. Complex workload cont. Figure 11. Randomly batch read/delete files
11/17/2018

17. Drawbacks
When tiny file is modified to become a large one, such modification requires additional operations.
The storage of directories is not space efficient.
However, yyfs does have its drawbacks. The first issue is that when a tiny file is modified to become a large one, such modification requires additional operations, This issue is an inherent in our strategy that no inode structure is allocated to tiny file.
The second issue is that the storage of directories is not space efficient. In yyfs, a directory block contains only directory entries, and each directory occupies at least one directory block. Though this is not an inherent problem with our design strategy, space efficiency may be compromised when users construct deep directory structures.
(Thinking of an extreme case when a user constructs a 100-level directories, with each parent directory contains only one child. To address the first inherent issue, additional strategy or/and data structures are needed. To address the second issue, compacting the directory is required. Compacting the directories that directly share the same parent is preferred, as more reference locality is expected among them.)
11/17/2018

18. THANK YOU!
11/17/2018