-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
I'll post other set of results done on real hardware. The virtual machine simply does not have enough CPU power, and the virtual disk is also slow.
Here I repeat the test on real hardware. I have used a script with variations as I find out things; when the difference is significative, I repeated the test. I'll post the script below. I did this on my same main machine, but on a spare 1TB HD. I reuse the same test partition, creating a different filesystem in the script prior to testing it. It was done on 12.3 system, I do not have available a 13.1 partition on this machine yet. Sorry about that. The first test is simply one to try to fill the partition to capacity with very small files (100B), written to the same directory This is intentional: it is a kind of load for which reiserfs was designed for, as the goal of these tests is to find a replacement for reiserfs. Well, reiserfs is still the king on this test, there is no replacement, period. Filesystem formatting are all defaults, no adjustments of any kind. Another finding is that I made the system to crash, several times (kernel crash or even panic). The crash seems related to the btrfs partition. Two theories: the filesystem would get corrupted during the test, or the system got confused when the btrfs partition was reformatted as something else and reused. I have not analyzed this. (In the previous test on virtual hardware with 13.1 RC1 the btrfs partition would get corrupted beyond repair. Despite erasing the files, and being no snapshots, the metadata would not be freed. Or some other explanation. I had to reformat the partition to recover it. Either it doesn't like the small file stress test, or it doesn't like to be filled to capacity. At least, the kernel would not crash. Yes, there is a bugzilla.) Partition of 8000MiB (7.81 GiB) Fill test - up to 10 million files files, 100 bytes each. number | time (real/user/sys) | listing time | rm files time | used free % of files | | (real/user/sys) | (real/user/sys) | space space reiserfs 10001000 | 182m19.821s/9m34.975s/30m20.041s | 1m24.464s/1m20.187s/0m3.848s| 7m38.435s/0m8.169s/5m15.013s | 2.2G 5.7G 29% ext4 512051 | 28m 4.919s/0m30.328s/20m13.093s | 0m 0.856s/0m0.618s/0m0.250s | 0m33.213s/0m0.546s/0m10.289s | 2.2G 5.2G 30% fail ext3 512051 | 28m 1.007s/0m30.820s/20m3.668s | 0m32.291s/0m0.559s/0m9.764s | 0m 0.860s/0m0.613s/0m0.257s | 2.2G 5.2G 29% fail xfs 1509755 | 25m 0.937s/1m21.044s/4m17.662s | 0m 1.657s/0m0.923s/0m0.531s | 1m31.523s/0m1.413s/0m52.991s | 6.7G 1.2G 86% fail btrfs +5555076 | 493m43.155s/6m32.774s/24m9.205s | 2m39.443s/0m3.718s/0m3.267s | kernel panic! | 5.7G 808M 88% fail ext3/4 fail soon enough. The limit is apparently lack of inodes, as there is plenty of space available. xfs apparently converts disk space to metadata on the fly, it allows 3 times as many files as ext3/4, and in less time! btrfs... Well, btrfs is fast till some point, when it starts to go slower, and then crawl. When there were about 810 MB free (about 4 million files), writing would stop for a minute or more about every 50 files, with cpu almost 0 (50 id, 50 wa)). The only busy task was btrfs-submit-1. The entire system was slowed, windows would not redraw, keyboard would lag. It is possible that if the test disk were different from the system disk results might be different. I had to force the test to abort by filing the rest of the partition with a big file (the idea was to abort and get the timings), using: rescate2:~ # time dd if=/dev/zero of=/data/Test/dummy dd: writing to ‘/data/Test/dummy’: No space left on device 1651458+0 records in 1651457+0 records out 845545984 bytes (846 MB) copied, 1158.74 s, 730 kB/s real 19m57.715s user 0m0.371s sys 0m5.646s rescate2:~ # rm /data/Test/dummy # - instant. Notice the time: I let it run for about half a day! Well, 8 hours, apparently. Five and a half million files, which is impressive - but unusable slow. reiserfs... I wrote TEN MILLION small files on a single directory on reiserfs, in about 180 minutes. Well, that's really impressive. And it seemed happy to accept many more, but I had to stop somewhere... :-) I'll put on another email the results of testing a larger partition with fewer files. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJs8qsACgkQtTMYHG2NR9XAIgCeL0bo+/pWM7d3/G/eyLf5et5O ayYAn0QTlXqVgjhe2kROE+w1dbEJ9xEj =jOkc -----END PGP SIGNATURE-----