Episode Details

Today on BSD Now, the latest Dragonfly BSD release, RaidZ performance, another OpenSSL Vulnerability, and more; all this week on BSD Now.

This episode was brought to you by

href="http://www.digitalocean.com/" title="DigitalOcean"> href="http://www.tarsnap.com/bsdnow" title="Tarsnap">

Headlines

DragonFly BSD 4.8 is released

• Improved kernel performance
  • This release further localizes cache lines and reduces/removes cache ping-ponging on globals. For bulk builds on many-cores or multi-socket systems, we have around a 5% improvement, and certain subsystems such as namecache lookups and exec()s see massive focused improvements. See the corresponding mailing list post with details.
• Support for eMMC booting, and mobile and high-performance PCIe SSDs
  • This kernel release includes support for eMMC storage as the boot device. We also sport a brand new SMP-friendly, high-performance NVMe SSD driver (PCIe SSD storage). Initial device test results are available.
• EFI support
  • The installer can now create an EFI or legacy installation. Numerous adjustments have been made to userland utilities and the kernel to support EFI as a mainstream boot environment. The /boot filesystem may now be placed either in its own GPT slice, or in a DragonFly disklabel inside a GPT slice.
  • DragonFly, by default, creates a GPT slice for all of DragonFly and places a DragonFly disklabel inside it with all the standard DFly partitions, such that the disk names are roughly the same as they would be in a legacy system.
• Improved graphics support
  • The i915 driver has been updated to match the version found with the Linux 4.6 kernel. Broadwell and Skylake processor users will see improvements.
• Other user-affecting changes
  • Kernel is now built using -O2.
  • VKernels now use COW, so multiple vkernels can share one disk image.
  • powerd() is now sensitive to time and temperature changes.
  • Non-boot-filesystem kernel modules can be loaded in rc.conf instead of loader.conf. ***

#8005 poor performance of 1MB writes on certain RAID-Z configurations

• Matt Ahrens posts a new patch for OpenZFS

Background: RAID-Z requires that space be allocated in multiples of P+1 sectors,because this is the minimum size block that can have the required amount of parity. Thus blocks on RAIDZ1 must be allocated in a multiple of 2 sectors; on RAIDZ2 multiple of 3; and on RAIDZ3 multiple of 4. A sector is a unit of 2^ashift bytes, typically 512B or 4KB.
To satisfy this constraint, the allocation size is rounded up to the proper multiple, resulting in up to 3 "pad sectors" at the end of some blocks. The contents of these pad sectors are not used, so we do not need to read or write these sectors. However, some storage hardware performs much worse (around 1/2 as fast) on mostly-contiguous writes when there are small gaps of non-overwritten data between the writes. Therefore, ZFS creates "optional" zio's when writing RAID-Z blocks that include pad sectors. If writing a pad sector will fill the gap between two (required) writes, we will issue the optional zio, thus doubling performance. The gap-filling performance improvement was introduced in July 2009.
Writing the optional zio is done by the io aggregation code in vdev_queue.c. The probl