HAMMER VFS - The backend flusher now sorts inodes
* Change the tailq of inodes in a flush group to a red-black tree.
The flusher now processes inodes in sorted order and breaks them up
into larger sets for concurrent flushing. The flusher threads are thus
more likely to concurrently process inodes which are fairly far apart
in the B-Tree.
This greatly reduces lock interference between flusher threads. However,
B-Tree deadlocks are still an issue between inodes undergoing flushes
and front-end access operations. This can be observed by noting periods
of low dev-write activity in 'hammer iostats 1' output during a blogbench
test. The hammer-S* kernel threads will likely be in a 'hmrdlk' state
at the same time.
* Add sysctl vfs.hammer.limit_reclaim to set the maximum
number of inodes with no vnode associations, default 4000.
NOTE: For debugging only, setting this value too high will blow
out the kmalloc pool.