After installing the new Ubuntu (Xubuntu) 14.04, I rebooted the machine to the desktop. I noticed that the hard drive was being accessed every second consistently. Just pulse...pulse...pulse. It was driving me nuts, as I had no clue what could be causing it. Since this issue was IO related the easiest way to solve this was to install and run iotop.
# Install iotop sudo apt-get install iotop # Run IOTop with -o so we only see processes doing IO iotop -o # Output looked similar to this Total DISK READ: 0.00 B/s | Total DISK WRITE: 2.00 M/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 1 be/4 root 0.00 B/s 2.00 M/s 0.00 % 3.00 % [ext4lazyinit]
Now I know anything in brackets is a kernel thread, and ext4 is the file system I used (Ubuntu uses) to format the partitions. Time to go see what this kernel thread does. After some digging I found the Git commit log for this ext4 file system feature.
In the old (or not so old) days of ext2 and 3 when you formatted the file system you would have to wait while it was created. Usually most of the waiting was because you had to wait for the inode tables to be created. Make a ext3 file system and watch how long it takes to make the inode tables. The bigger the drive the longer it takes to make these tables. We are talking 10 or more mins on 2TB drives and above. Ted Tso the creator of ext4 helped cut this time down by allocating some of the inode tables during creation and then allowed the rest of them to be made on first mount. When the file system is mounted the first time it sees this was marked to be done and creates a background kernel thread to finish creating the inode tables. This way your install time is cut down dramatically because you don't need to wait for the file system inode tables to be created. The are just happily created in the background as you work.
So how long will this take to finish? I'm not to sure as I left my machine on all night so it could finish. It was done by the morning so I can say less than 12hrs on a 1TB drive. Don't fret though it will eventually finish and rest assured there is nothing wrong with your hard drive or the install. This likely happens on older Ubuntu installs and any other distros that use ext4 as well.
I always seem to come across this error every time I'm trying to partition a drive with parted. I want to use the whole drive, but I can never seem to get the alignment right. When you try to partition a drive using parted and you do the "mkpart" command you have to choose partition name, file system type, start, and end. The start and end is where I have the issue. Do I start on zero or 1 and how do I easily know what the end of the disk is? When you do this wrong the error you usually get is "Warning: The resulting partition is not properly aligned for best performance.". That error does not inspire confidence. Here is the best way I have found to use the full disk size with 1 partition.
When asked about start and end we are going to use percentages like so.
(parted) mkpart Partition name? ? 1 File system type? [ext2]? ext4 Start? 0% End? 100%
You could also do this from the command line like
sudo parted /dev/sda mkpart primary ext4 0% 100%
Doing this will leave some free space at the start and end of the disk, but it will make sure the partition is properly aligned for best performance.
(parted) print free Model: ATA SAMSUNG SSD 830 (scsi) Disk /dev/sda: 128GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 17.4kB 1049kB 1031kB Free Space 1 1049kB 128GB 128GB primary 128GB 128GB 335kB Free Space
One last check for alignment.
(parted) align-check opt 1 1 aligned
Back in 2012 I wrote an entry that said to not use FreeBSD 9.0 as a PF firewall. It was mildly controversial and I was just relaying my experience of installing FreeBSD 9.0 on release day. It was a frustrating experience that I really wanted to work out and I was sadly disappointed that it did not. I wanted to try it again in the future in hopes that the FreeBSD team could put together something that work work better for me. That time is now.
Reading about all of the improvements in FreeBSD 10 was very encouraging. Some of the most encouraging things that inspired me to try again was a fork of PF. The FreeBSD devs forked PF because Gleb Smirnoff wrote an amazing patch to make PF SMP-friendly. But this was not compatible with the newest PF code so hence the fork. Making PF SMP aware improves performance immensely. OpenBSD has not done this nor does it look like it is on their radar.
Since I tried it last the binary package system for FreeBSD has been rewritten. The new package system pkgng is a major improvement over the old package system. Now FreeBSD actually has a package manager that can deal with dependencies well and we can live off of binaries instead of ports (Yea!).
I have been really interested in using ZFS as a file system, and our friends over at Calomel.org have convinced me that the time is right to try it. ZFS has added TRIM support in FreeBSD 10. ZFS also has added LZ4 compression, which is an amazing new fast compression algorithm. Plus you can now install ZFS as your root drive right from the installer. I do wish they would add the ability to choose options like compression during your ZFS install, but hopefully they will add this as advanced options in the future.
The install went great. I followed the great instructions from our friends over at Calomel.org and made my usb boot drive. I fetched the script from Calomel.org and changed a few things. I ran the script and a few mins later I rebooted and hit a nice big error screen.
The error was "ahcich1: Timeout on slot 30". This error was referring to the first channel on my SATA port where my hard drive lives. I could not figure out why it was having this issue until I checked my BIOS. My drives were set to IDE instead of AHCI. For some reason FreeBSD installed fine using IDE as the setting, but on first boot it fell flat on its face. AHCI is better and is what I really wanted it set to, but I never bothered checking. After changing to AHCI in the BIOS FreeBSD booted right up.
The install was done on my internal network so I had the ability to use another machine to do the install and download everything I needed to get it done. Then I tried hooking it up to my external firewall. I could not get lease from Verizon's DHCP server to save my life.
In the install script I used you have to change your external interface to DHCP and change (spoof) its MAC address to match the MAC that Verizon has in their system. This could be the MAC of your original router or your Verizon router. That MAC was changed correctly to what I have on the OpenBSD machine the was hooked up, but I could not get a lease from the Verizon DHCP server at all.
Long story short, with Verizon you have to release the DHCP lease before you can get a new one. With FreeBSD there is no way to release a DHCP lease with the version of dhclient that comes with FreeBSD. In the Linux version of dhclient you can. I had to end up hooking up my old Verizon router and push the "Release" button on the GUI interface. After doing that and quickly powering off the router I booted right up and got a lease. Now, I also believe if I waited enough hours I could have waited for the lease to expire, but I wanted to get this done so I found a faster way.
Installing and configuring the system was pretty easy. I worked through many of the issues I had last time. Let me give you some examples.
Before I used to use Postfix with SASL to talk to remote mail servers using TLS. I now use OpenSMTPD to do this as it is built in and they also have built in CA Certs for Gmail. That solved the annoyance of having to build Postfix from ports. As far as I can tell FreeBSD still does not build Postfix with SASL, but they do build Sendmail with SASL. Go figure.
PF still works great in FreeBSD, but they still do not build in ALTQ as a kernel module or into the kernel. This is not as big of an issue for me as it once was since turning it off I did not see any noticeable difference on my home network. For a big corp that has lots of different users this might be different. For me I can live without it for now as turning it on requires a kernel recompile and I'm trying to avoid that. OpenBSD is abandoning its work on ALTQ as they said it was a hack in the fist place and the code is showing its age with limited 32 bit registers and the like. They are working on a new queuing system called prio. I hope FreeBSD can eventually work this into their fork of PF or make one of their own. What I really want back from ALTQ is priority ACKs. I wish someone would hack in priority acks into the tcp stack as a kernel tunable. That would rock.
All PF tools I installed from packages this time and they worked great right out of the box. No fuss at all. This was a big improvement from last time as most of the PF tools were broken on release day.
In the last entry I bid farewell to FreeBSD, but this time I'm waving bye bye to OpenBSD. OpenBSD we need to talk. You are falling behind. FreeBSD is eating your lunch on performance and features.
I'm not saying I won't be back OpenBSD, but I'm going to ride the FreeBSD train for now and see where it takes me. Thanks for all of the stability and security you have given me over the years. Good luck and I hope you can start addressing the issues I mentioned above.