4 ms·
It seems like you may be jumping to conclusions a bit prematurely. The paper (https://www.cs.unc.edu/~porter/pubs/fast15-final.pdf https://www.cs.unc.edu/~porte
by williamkuszmaul 5y ago
It seems like you may be jumping to conclusions a bit prematurely. The paper (https://www.cs.unc.edu/~porter/pubs/fast15-final.pdf https://www.cs.unc.edu/~porter/pubs/fast15-final.pdf) is very explicit that they start with a cold cache. They also go into detail for why they do well on grep. As I understand it (but I'm not an expert), betrfs's advantage here comes from the fact that it stores files lexicographically by their full names (and metadata), meaning that related files are stored nearby each other on disk. This gives better locality than what you would get with a standard inode structure.
Based on that, it seems like the outcomes of the tests are pretty reasonable.
- mnw21cam 5y agoI'll concede on the hot cache suggestion. Storing the files lexicographically is an interesting thing - it means that grep/find (or anything else that reads through the files/directories in order) would perform well. But this makes the test to some extent contrived to specifically run fast on this particular system. I do agree that this kind of filesystem mechanism should give good performance benefits. But in the general case they won't be quite as fantastic as these benchmarks make out.
- donporter 5y agoPlease note that the benchmark sources are also available, e.g.; https://github.com/oscarlab/betrfs/blob/master/benchmarks/micro/large-file/random_write.c https://github.com/oscarlab/betrfs/blob/master/benchmarks/mi...