The pkgsrc ‘freeze’ in preparation for the pkgsrc-2011Q2 branch is coming up, starting this Sunday the 19th. This means the quarterly release will be tagged in about 2 weeks, and I’ll probably have binary packages built for DragonFly about a week or so after that.
BSDDay Argentina is starting to look for speakers. The official site doesn’t list 2011 dates yet, but it’ll be in November, in Buenos Aires. (via Damian Vicino) Alex Hornung gave a DragonFly presentation there last year…
Venkatesh Srinivas is making vmobj_token and vm_token much more fine-grained. That’s great, but watch out over the next few weeks as this work goes into 2.11. (i.e. don’t upgrade your DragonFly 2.11 unless you are ready for surprises.) Venkatesh has already found some.
Do you have a DragonFly workstation? That you play audio on? Do you have headphones hooked up? Is it using Intel High Definition Audio? (snd_hda) Does connecting the headphones disable the system speaker?
You can probably guess exactly what I’m trying to troubleshoot given the above questions.
Here’s two items I meant to post and for some reason did not:
- Sven Gaerner posted a short description of how he migrated his DragonFly system from a hard disk to a SSD. This may be useful for anyone considering a move. Decent-sized SSDs are reaching low prices these days.
- Tim Bisson posted an update on his work on TRIM support for DragonFly. The code is available now if you’re feeling lucky.
It’s World IPv6 Day. You can go to IPv6 right now with your DragonFly system. If your ISP doesn’t support IPv6, you can try a sixxs or HE tunnel. Also, nag your ISP about it.
The i386 architecture now supports LAPIC and I/O APIC. If you had weird interrupt problems when installing DragonFly before, now might be a good time to try the latest bleeding-edge version of DragonFly and see if the problem vanished.
Sepherosa Ziehau’s made it possible for uniprocessor kernels to use the LAPIC and IOAPIC functions on x86_64, which means better timer support, less need to fiddle with configs, and more supported hardware. A win all around! Set hw.lapic_enable=”0″ if there’s trouble. The same changes for i386 are on the way.
The dragonflybsd.org network is going through some network changes; access may be spotty in the next… 24 hours?
The June issue of BSD Magazine is out, with the title being “NanoBSD and Alix”, but there’s plenty more articles in there. DragonFly news is on page 25 – if this month is better for me than last month, I hope to have more in there.
Stéphanie Ouillon has posted extensive details on the Virtio Google Summer of Code project; a few questions are included for anyone who wants to jump in and offer feedback.
Fresh from BSDCan 2011, an interview with Ingo Schwartze and Kristaps Dzonsons, mostly about mdocml. (Which is already present in DragonFly.)
I moved to DragonFly 2.10 over the past few days, and I tried out deduplication, to see what kind of results I would get. The procedure is outlined below. I’m using /home here as an example, just to reduce the amount of text pasted in.
/pfs/@@-1:00004 966000640 566434576 399566064 59% /home
Move my various Hammer pseudo-file systems to version 5, which supports deduplication.
# hammer version-upgrade /home 5
Issue a deduplication simulate command, to see what it guesses will be the savings:
# hammer dedup-simulate /home
Dedup-simulate /home: objspace 8000000000000000:0000 7fffffffffffffff:ffff pfs_id 4
Dedup-simulate /home succeeded
Simulated dedup ratio = 1.22
That ratio turned out to be pretty accurate for the actual deduplication. I didn’t time it, unfortunately. I don’t know if the time taken is proportional to the amount of deduplication or the total volume of data, though I suspect the latter.
# hammer dedup /home
Dedup /home: objspace 8000000000000000:0000 7fffffffffffffff:ffff pfs_id 4
Dedup /home succeeded
Dedup ratio = 1.22
462 GB referenced
378 GB allocated
14 MB skipped
6869 CRC collisions
0 SHA collisions
0 bigblock underflows
The end result?
/pfs/@@-1:00004 966000640 505887504 460113136 52% /home
That data space is shared across all file systems, and it’s a 1TB disk, so it’s 7%, or 70GB. I was hoping for more, but I don’t have any obviously duplicated data (no local mail store, no on-disk backups), so perhaps this is normal. 70GB that I didn’t have before is no bad thing, though.
Incidentally, I was able to upgrade my installed software from pkgsrc-2009Q4 to pkgsrc-2011Q1 entirely using pkg_radd -u <pkgname>. Remarkably quick and painless, though pkgin may have been able to do it even faster since it would pull from the same place.
This new build is on x86_64, pkgsrc-2011Q1. It’s already uploaded, if you want to update. i386 coming soon. Several packages freeze up during build, so it’s been turning into a manual process.
I haven’t covered recent disk encryption work evenly, here, so I’ll point at a recent discussion instead. Alex Hornung mentioned a cryptsetup(8) man page that may help, as does any dm-crypt tutorial out there on the Internet. (DragonFly has the same userland tools.) The DragonFly installer will create encrypted disks at install time, too.
If you follow this thread, it has some discussion on how to handle a multi-disk setup and Hammer. If a disk is going bad, you can try mirroring, though you have to be careful how your pseudo-file systems are set up.
The SMP option is now in the GENERIC kernel config. This means you’ll have a SMP-capable kernel even on an uniprocessor machine, unless you configure a special kernel.
Apparently the mail(1) and battlestar(6) source code caused a problem when checked out onto a NTFS volume. Sascha Wildner fixed it, and Alexander Polakov found an explanation as to why. How long has this problem been around? Well, look at the email addresses at the end of the man page for battlestar(6), for instance, or guess how long mail(1) has been around…
The I/O APIC is now always on unless you say otherwise. This may not make a clear difference to you, but enabling that kernel option has always been a somewhat iffy thing; working for some configurations and not others. Now, it’s one less thing to worry about.