EuroBSDCon 2009 – pictures

EuroBSDCon 2009 and the preceding dev summit happened last weekendq in Cambridge, UK. Robert Watson, who has organised this successful event, noted that the FreeBSD Developer’s Summit was the largest yet in the EU with around 70 attendees. The conference was attended by about 180 attendees, and the dinner sponsored by iXsystems was sold out.

Slides, papers, and audio recordings should be available soon on the UKUUG website. Will let you know when they’re up.

Rodrigo Osorio has posted some pictures here and a couple of my eurobsdcon photos here.

View photos

FreeBSD 8.0-RC1 available

The first of the Release Candidates for the FreeBSD-8.0 release cycle is now available, as announced by Ken Smith.

“The first of the Release Candidates for the FreeBSD 8.0 release cycle is now available. How many RC’s we have will depend on how well 8.0-RC1 does. At the moment only one more RC is on the schedule but odds are fairly high we will wind up inserting at least one more RC. Between BETA4 and RC1 a lot of work has gone into IPv6 issues as well as many other issues that have been brought up from the public testing. And a patch set was committed by the people who handle porting ZFS to FreeBSD that they felt makes ZFS production-ready.”

There are still a few problems and outstanding issues, but hopefully they’ll get soon fixed.

FreeBSD 8.0 RC1 ISO images and a “memory stick” image for amd64/i386 architectures are available to download from the project’s mirrors. Users currently running FreeBSD 7.0 or later can upgrade via the freebsd-update utility. The final version of FreeBSD 8.0 is expected to be released in “early October”.

FreeBSD 8.0 – BETA 4 available

freebsd project logo 100x100Ken Smith has announced the fourth and last of the BETA builds for the FreeBSD-8.0 release.

The fourth and most likely final BETA build for the FreeBSD 8.0 release cycle is now available. We expect the next test build to be the first  if the Release Candidates, RC1. Since BETA3 many bugs that were identified from testing done so far were addressed. Some of the bigger issues were an mbuf leak along with work done in the general IPv6, jail, and usb subsystems. Issues in other areas have been addressed as well.

Due to the issues identified in this early phase of testing the schedule for release has been pushed back. The current target for the release itself is September 29th, with two RC builds between now and then. Details about the current target schedule along with much more detail about the current status of the release is available on the FreeBSD 8.0 todo page

ISO images for Tier-1 architectures and a memory stick image for amd64/i386 are now available on most of the FreeBSD mirror sites.

VirtualBox: how to move FreeBSD to a new hard disk

Georges has written a post showing how to move a VirtualBox FreeBSD system to another, larger, VirtualBox drive:

“Let’s say that, like me, you once created a fixed-size virtual disk in VirtualBox, and installed FreeBSD on it. Now you’ve run out of disk space and you’d like to move your FreeBSD to a bigger-sized virtual disk. Here’s how I did it. This procedure was done with VirtualBox 2.0.{4, 6} on Windows XP.

First, with VirtualBox not running, make a backup copy of the whole .VirtualBox folder, just in case.

Start VirtualBox and select your FreeBSD virtual machine.

In Settings, Hard Disks: create a new Hard Disk, fixed-size. As the currently active HD is IDE Primary Master, the new HD will automatically be an IDE Primary Slave.When it’s done, click OK. The FreeBSD VM now has two hard disks. It’s like you’ve just added a new hard disk inside a real machine, a blank unformatted disk, which will be detected as a top-level IDE device (/dev/ad1) by the kernel.”

Go here for all the needed steps

FreeBSD, rock solid and stable (proof)

We all know that FreeBSD is a rock solid, ultra stable and reliable (server) operating system.

Here’s another proof. Nick Rogness reports:

We have recently decommissioned a web server which was running FreeBSD 4.11 on a HP DL380 G3. It was hosting websites for over 20,000 subscribers and was rarely idle for any length of time.

The uptime achieved when we powered it down was 1004 days, 1 hour, 34 minutes, 56 seconds. One of our tech’s took a snapshot of the shutdown screen with his cellphone and is available at if interested.

Yet another example of the stability and reliability of FreeBSD!!
Thanks for all the great work!We have recently decommissioned a web server which was running FreeBSD
4.11 on a HP DL380 G3. It was hosting websites for over 20,000 subscribers and was rarely idle for any length of time.

The uptime achieved when we powered it down was 1004 days, 1 hour, 34 minutes, 56 seconds. One of our tech’s took a snapshot of the shutdown screen with his cellphone …

Yet another example of the stability and reliability of FreeBSD!!

Source (FreeBSD Advocacy Mailinglist)

Finishing up the FreeBSD Xen port

There’s been an active discustion on the FreeBSD Xen mailinglist about finishing the Xen port.

Xen is a virtual machine monitor for IA-32 (x86, x86-64), IA-64 and PowerPC 970 architectures. It allows several guest operating systems to be executed on the same computer hardware concurrently. Xen was initially created by the University of Cambridge Computer Laboratory and is now developed and maintained by the Xen community as free software, licensed under the GNU General Public License (GPL2). (Wikipedia)

The Xen port has never been complete and had some issues. A couple of developers have now decided to get together, get some hardware and financial support toegether to make it happen this time.

For over 3 years we’re now looking at a mostly-working, breaking, half-working port, breaking, half-working of FreeBSD to xen. Personally I think this is a very sad state, especially considering how well FreeBSD (-current, with patches) worked in Xen 2.

I wonder if starting a fundraiser might help this problem. I think we would have to scratch up enough for a month of kip’s (or someone else’s) time to see everything addressed and the xen patches finally being
merged in a same way like NetBSD did it.

Assuming that most people do not very much care about their dom0 OS, but strongly care for running FreeBSD (instead of Linux, NetBSD, Solaris flavours) for their virtualized servers, it would be the best way to go to make almost everyone happy.

… I’m completely sick of having to tell people … that “it used to be working but right now it’s not stable for production use, but it might actually build right now” and point them at one of the above OS according to
their needs, when actually they’d just love FreeBSD.

Honestly, I do not believe this state will *ever* get better without some massive effort and I’m very much looking forward to some discussion about this. It think the support should get -stable’d while the linux kids are still trying to make ZFS work stable :)

What it takes to get the port together is:

  • Initial work to bring -head’s Xen support back to scratch - primarily AFAIK a lot of SMP/PMAP attention
  • backporting that to 8-stable * the decision that Xen should be supported, and enough support showing up to make it happen
  • enough ongoing support and developer interest in keeping it up to date.

FreeBSD Xen wiki

Meta Ports to install group of ports (FreeBSD)

Often, after a fresh new installation of FreeBSD, we have a set of programs we want to install. The conventional method would be installing it one by one in /usr/ports. Today, we will use meta ports to install the set of applications by just one “make install clean” rather then “cd” into individual directories and do “make install clean” for every ports.

Meta ports are, as the name implies, ports file that describe about the program we are installing. The ports file describe where & what to install for this ports to work. A sample of “where” would be “where to download the source“, “where to install it” and so on. As for “what“, it would be “what to install to fulfill the dependencies“. In this post, we will take advantage of this “what“. We will define the dependencies as the list of programs we want to install so that the ports will install it.

Here’s an example how to set up a meta port

Thanks Edmondas, for emailing me the link.

twIP on FreeBSD

twIP (pronounced “twip” and short for tweet IP) runs as a process under a *nix-like system, but could also be run on a standalone (OS-less) device, as long as there is a device driver for some networking hardware. The underlying system must provide a way to receive and send raw data packets. Operating systems such as FreeBSD (and others) provide a very nice mechanism called the tun/tap device, where a special file (/dev/tun0) is connected to a network interface (tun0) so that packets sent over the interface can be read from the file, and packets written to the file appear as packets on the network interface. By setting up the IP address of the network interface, routing IP packets to the user program is a breeze.

twIP is a really, really tiny IP stack, written in 139 bytes of C code – small enough to fit in a Twitter message. Ok, so it is very far away from a real IP stack, but it can do the first task of an IP stack: respond to pings. The entire source code for version 1.1 can be found this tweet (139 characters long – version 1.0 in this tweet, 128 characters long).

More twIP info and source code

UFS file system space allocation policy

Ivan Voras has an interesting post explaining UFS file system space allocation:

Users coming from other systems don’t usually know it (and probably don’t care, in today’s environment of multi-TB drives), but UFS has a rather interesting approach to space allocation which is different from the “usual suspects” like ext2/3, NTFS and FAT(32). Though it sometimes feels “interesting” in the sense of the Chinese proverb, it’s time-tested to work.
I’m talking about clustering, blocks and fragments.

As in more common file systems like ext2/3, NTFS and FAT/FAT32, there is a concept of a “block” or a “cluster” of sectors. Typically, 8 sectors of 512 bytes are clustered together to form a block of 4 kB in size – with time this has become the “traditional” cluster size and is used by default on ext2/3, NTFS and, if drive sizes permit, FAT/FAT32.

This form of clustering means the operating system must maintain less data about what blocks are allocated and where. Since average file size is certainly larger than the sector size (which is the absolute minimum size allocatable on the drive), it makes sense to use a bigger amount of space and consider it “atomic”.

This has two obvious consequences: first, a 1-byte file takes 1 block of space, eg 4 kB and there is nothing to be done about it. Second, all “normal” files usually have some padding at their end to fit on a 4 kB boundary. Even if the operating system records that a file is exactly 5000 bytes in size, it will internally consider this file to take 2 blocks (8 kB). The space between the logical end of the file (5000 bytes) and the accounted space (8 kB) is irrevocably wasted. All usable file systems have variable block sizes; some file systems like FAT and FAT32 have built-in limitations that dictate minimum block (cluster) sizes depending on the drive size – a FAT32 file system of 64 GB will have to use a minimum cluster size of 32 kB to avoid memory and performance problems, meaning up to 32 kB is wasted on small files and there is usually large padding space at the files’ ends.


More about UFS on Wikipedia