A running description of activity related to DragonFly BSD.
I knew about files like /etc/services, for common IP port usages, and /usr/share/zoneinfo, for time zones, but I didn’t know that DragonFly (along with other systems) keeps a list of agreed names for various human languages defined by ISO639 in /share/misc/iso639, and it’s maintained at least in part by the Library of Congress. At least I didn’t know until Sascha Wildner updated it.
Updated: Birthstones and flowers. Don’t know why.
Do you use ndis(4) for a network card that would otherwise not work? Are you running DragonFly 3.3? Are you willing to run USB4BSD and see if it works? If you do, tell Sascha Wildner if his changes worked.
If you are one of the few people still wanting to read an OS/2 HPFS drive, support for it in DragonFly has been updated by Antonio Huete Jimenez. It’s read-only, but writing didn’t work well, and I’d be surprised if there’s any hpfs disks that aren’t archival, out there.
Also, Sepherosa Ziehau has updated the pktgen program to generate even more packets, even at relatively low CPU clock speeds.
The initial download of pkgsrc via Git on DragonFly is a little bit faster now, with the ‘make pkgsrc-create-shallow’ option recently added by John Marino. Note that there’s a similar option for src. It skips downloading file history.
Peter Avalos has updated OpenSSH in DragonFly to 6.1p1. This looks to be a bugfix release, but check the changelog for details.
John Marino’s committed bmake as the replacement to make, as mentioned previously. You should probably do a full buildworld/kernel sequence. This of course only affects you if you are on DragonFly 3.3.
Matthew Dillon’s put more of his Hammer work into DragonFly, with notable parts being the creation of a ‘dmsg’ setup for advertising available block devices to share between machines using Hammer. To anticipate your next question: No, it’s not something you can run right now as a test; this is the underlying framework.
The kernel in DragonFly is now SMP by default. The “SMP” option in the kernel config is no longer needed, so it’s been turned into a no-op. You don’t have to update your custom kernel config… yet.
A conversation about compilers in the DragonFly base system led peeter (must) to describe his group’s use of OpenMPI on DragonFly for physics calculations. Apparently he’s had a significant performance improvement on DragonFly.
Along similar lines, John Marino helped out by bringing in libssp and libgomp for gcc 4.7 for use with OpenMP. (This is in DragonFly 3.3, not 3.2).
Remember the new scheduler work? Well, it continued, and now Francois Tigeot has posted pgbench benchmarks of the progress and benchmarks of DragonFly vs. other operating systems. The links are to PDFs; scroll down as each have multiple pages.
The summary result: If you’re running Postgres, you probably want to do it on DragonFly. The numbers are the best results for any BSD, even better to some extent than Linux, which has had its own issues with schedulers and Postgres. DragonFly 3.2 will include these improvements.
John Marino has accomplished the difficult task of putting gcc 4.7 into DragonFly. Version 4.4 is still the default, and the older 4.1 version has been disabled. If you want to try this newer version, setting WORLD_CCVER=gcc47 will build kernel and world that way too. If you’re curious about what’s different in this version of gcc, there’s a 4.7 changelog.
Are we the only BSD with this new a version in base? I think so.
P.S.: You’ll want to do a full buildworld if you’re running DragonFly 3.1
P.P.S.: you may need to put ‘NO_GCC47=true’ in make.conf, going from IRC comments.
P.P.P.S.: Nope, now it’s fine.
The combination of Mihai Carabas’s successful Summer of Code work on the scheduler and the recent Postgres benchmarking got Matthew Dillon to start thinking about making UNIX domain sockets work better, a shortcut around the buffer cache, scheduler improvements and then a new default scheduler, along with a change in idle CPU behavior. The best place to understand all the changes is in his long post to users@.
We should have benchmarks soon to show the performance improvements from all this.
If you do, they don’t get cleaned up during the normal ‘hammer cleanup’ nightly routine. Chris Turner has added a way to manually specify them as a cleanup target.
I’m pretty sure in this case ‘offline’ means ‘nothing streaming to it from a master disk’. I think.
Matthew Dillon has created an experiment: shared page table mappings. It’s controlled by a sysctl, since it’s still experimental. The real-world effect is reducing the number of memory faults as a process uses up memory, and decreasing the overall memory usage. The obvious benchmark is Postgres speed; this makes the initial expansion of memory usage much less of an drag on speed due to a high memory fault rate.
If all this mention of faulting sounds like a problem, remember memory faults on BSD are normal; that’s how programs indicate they need more memory space by causing a fault. This is in contrast to Linux, where memory is allocated a different way. Or at least, that’s my understanding. (If you know better, please comment.)
These are small, but they make life easier: Hammer now has a scoreboard file, for viewing of mirror-streams running in the background. There’s also a ssh-remote directive, so you can use ssh without enabling an interactive shell, and a HAMMER_RSH environment variable so different remote shells can be used. These are all for Hammer 1.
Antonio Huete has updated dhclient(8) to match the OpenBSD version from whence it comes. I think all (most?) the BSDs use the OpenBSD dhcp client as a base now. The only user-facing change I see in a quick reading of the changes is a new ‘egress’ command line option.
John Marino is working on updating tcl in pkgsrc. It’s apparently quite messy to update, which may be why it has sat out of date for some time. Never one to rest, he’s also been making FUSE filesystems work on DragonFly. (Here’s a FUSE explanation, if you need it.)
Also this. Someday I’m going to write a “games on DragonFly” feature, or series.
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.)