About TODO Blog RSS Old blog Projects Gallery Notes

Tue, 25 Mar 2008

Filesystem contest results.

Interested reader can check out results of the ext2/3/4, reiserfs, reiser4, jfs, xfs and btrfs fight for the first prices in dbench, iozone, postmark, maildir performance bench and simple file creation micro-benchmark.

It does not contain maildir benchmark, I will add it tomorrow or later today, xfs has yet not completed and no graphs.

As a conclusion: nothing major changed since previous contest, new btrfs filesystem behaves not that bad in some cases, but quite slow in others... Nothing changed.

Does it mean, that we need something new?

/devel/fs :: Link / Comments (3)

POHMELFS status.

I've started mostly from scratch, I think it is a good sign, when project can be rewritten without any pain to implement a really interesting ideas instead of having multiple crutches all over the place. This also means that it is not that complex, so I do not regret about dropped code.

Now it is in a very testing stage without network protocol at all, but I test new paradigm in the pohmelfs: its inodes will not be hashed into global hash table, but instead will be placed into local trie-like structure, which (optionally) will allow RCU-fied lookup. Something similar to data structure created for multidimensional trie used for unified socket lookup patch.

I very like two-hash approach, but since there is no proof (yet) it will work for all possible cases, I will first implement radix-like tree to store object names. Network protocol will also operate on full-length pathes, which actually can be a bad idea, I will see.

Another uber cool feature of the full-path approach is ability to create number of directories, which form a path to given object, in a single command, i.e. when client sends a network command to create object /a/b/c/d/file, there is no need to send separate commands to create /a, /a/b and so on, it can be done automatically by server. This requires to send not only path though, but also information about permissions for each subdir.

/devel/fs :: Link / Comments (2)

Second filesystem contest is over.

Although I plan to run additional couple of tests for btrfs, namely all tests for nodatacow option and without ssd option, which will likely take part of the day. But all others were already completed, so expect nice graphs tomorrow.

There was number of surprises during that testing. For example reiser4 constantly freezes the test box in dbench workload with 150-200 threads. There are no messages in dmesg, but nothing is turned on in kernel hacking section of the config. Both btrfs and reiser4 are very slow creating and writing into lots of small (4k) files. Reiser4 is two times faster than btrfs, the latter creates/writes/syncs/closes about 10 files per second average when 10k-30k files are created one-by-one.
Ext4 is also slower than any other (except above two) filesystem in this microbenchmark. Something strange was made during 2.6.20-2.6.24 kernel: above file creation microbenchmark produced much worse results for all filesystems (magnitude of 10 in some cases) compared to previous contest. Maybe sync code was implemented correctly, I do not know...

I will likely drop maildir benchmark results, since perl script which works there constantly tells me, that fsync() has invalid parameter...

So, wait about 12 hours (I have to have some sleep: do not mix absinthe with different red wines and beer, when I did that yesterday/today night, it was quite tasty, but not todays morning)

/devel/fs :: Link / Comments (0)