Hammer 2 status report

Matthew Dillon recent posted a status report for Hammer 2.  Of interest is the spanning tree protocol being built to handle messages between Hammer volumes.  As he says in the message:

For example, we want to be able to have millions of diskless or cache-only clients be able to connect into a cluster and have it actually work…

(No, it doesn’t do this, yet.)

Another SSD conversation

Pierre Abbat is curious about using Hammer on an SSD.  The discussion that came from that has some useful points, including notes that a straightforward SSD as disk works for most anything with Hammer other than very intensive database use, due to the history retention.  If space is an issue, swapcache on the SSD and attaching a normal HDD is a fine alternative.  A SSD with Hammer can leave some features off, though I’d argue that dedup is totally worth is.  Also, SSD speed is directly correlated with size.

TCP Segmentation Offloading added

Sepherosa Ziehau’s added TSO support (that’s TCP Segmentation Offloading”, or “Large Segment Offload” going by Wikipedia) within IPv4 on DragonFly, pushing segmentation work from the CPU to the network card.  There’s also some DragonFly-specific improvements.

There’s been a lot of commits from him lately focused around network card improvements; they haven’t been easily summarizable, but it’s worth watching if you are interested in high-bandwidth usage and the hardware to support it.

A change for bc(1), no change for man

Pierre Abbat noticed that bc(1)‘s usage of GNU readline something that wasn’t GNU readline made it harder to use; Sascha Wildner changed it to use libedit.  Pierre’s other complaint, that BSD man page output stays on-screen when completed, is a positive feature.  Linux systems that clear man page output enrage me, because I expect to be able to take advantage of my scroll buffer.