libpthreadbroken, fixed

If you are running bleeding-edge DragonFly, libpthread was broken for a short period.  If you built anything in the last … 12 hours?  You may want to rebuild it.  If that doesn’t describe you, it’s a nonevent.

It’s funny that I’m reporting a short-term break in bleeding-edge operating system code as any sort of surprise.  It shows something about how stable DragonFly-master is most of the time.

Optimized scoreboard for SACK

DragonFly now has a optimized scoreboard for SACK, thanks to Sepherosa Ziehau.  What’s that mean?  SACK is a way to make sure only the needed parts of a TCP transmission get retransmitted, when multiple packets are lost.  The scoreboard is where the packets needing retransmission are tracked.  So, the result of these improvements is better performance in packet-lossy situations.

(Please correct me if your understanding is better than mine; my explanation is based on stumbling around the Internet for a few minutes of reading.)

Booting in a VM tip

If you’re trying DragonFly 3 in a virtual machine, you may have noticed some issues in booting in (for instance) Qemu.  Sepherosa Ziehau committed a change that sets the sysctl hw.ioapic_enable to 0 in virtual environments.  It can always be turned back on, but the recent MSI/MSI-X improvements seem to cause trouble in some virtual environment.  You can also set that tunable at boot to get an initial install going.

(I haven’t had trouble in Virtualbox or VMWare, so you may or may not need this.)

GNU hash tables added

Another “first BSD to try it” feature: GNU hash table support has been added by John Marino.  These apparently speed up symbol searching during program startup, so it should improve large program startup time.  Think KDE or Open Office, though I don’t have numbers to back it up.

Deleting too fast

Here’s an interesting side effect that came up in Hammer 2 development: deleting files can potentially require modification of only one parent element.  If I’m reading it right, that means deletion always takes about the same time, independent of the amount of data being deleted.  Your ‘rm -rf /largedrive’ could complete, removing multiple terabytes of data before you realize it.  I suppose it’s silly to complain about speedy results.  Of course, being Hammer, it would still be available in history.