release42/index.mdwn

   1 # DragonFly BSD 4.2
   2
   3 * Version 4.2.0 released 29 June 2015.
   4
   5 Version 4.2 of DragonFly brings significant updates to i915 and Radeon support, a move to GCC 5 (and the first BSD to do so), a replacement to Sendmail, and numerous other changes including OpenSSL updates, a new boot screen, improved sound, and improved USB support.
   6
   7 The details of all commits between the 4.0 and 4.2 branches are available in the associated commit messages for [4.2RC](http://lists.dragonflybsd.org/pipermail/commits/2015-June/418748.html) and [4.2.0](http://URL HERE).
   8
   9 ## Big-ticket items
  10
  11 ### New base compiler
  12
  13 GCC-5 (gcc-5.1.1) is now the system base compiler as of the release.  The backup compiler is gcc-4.7.4.  This gives us significantly better C++ support which is needed for package building.
  14
  15 ### Improved graphics support
  16
  17 Significant progress continues in the drm (graphics) subsystem. Both radeon and i915 drivers have been updated, with i915 support seeing the most improvements.
  18
  19 ### Sendmail replaced by DMA
  20
  21 Sendmail has been replaced by the home-grown DragonFly Mail Agent (DMA) in the base system.
  22
  23 DMA is not a full-featured MTA (Mail Transfer Agent), it only accepts mails from local MUA (Mail User Agents) and delivers them immediately, either locally or remotely. DMA doesn't listen to network connections on port 25.
  24 People who still need a full-featured MTA must install it from dports. OpenSMTPD, Postfix and Sendmail itself are available as binary packages.
  25
  26 A [MTA wiki page](http://www.dragonflybsd.com/docs/docs/newhandbook/mta/) has been written to explain in details how to switch from DMA to a full-featured MTA on DragonFly 4.2 and more recent versions.
  27
  28 ## Changes since DragonFly 4.0
  29
  30 ### Kernel
  31
  32 * Fix an exec() optimization race that could deadlock processes.
  33 * Add reapctl() system call for reaper and sub-process management.
  34 * Improve slab cleanup performance.
  35 * Increase default MAXTSIZ from 128M to 256M.
  36 * Add lock cancelation features.
  37 * Implement a new callout*() core.
  38 * Fix callout deadlocks in u4b.
  39 * Fix a panic on upmap/kpmap access from procfs.
  40 * Fix a pmap panic in vkernel64.
  41 * Implement kqueue write filtering for U4B, required by some apps.
  42 * Fix a major pagetable memory leak that could fill up swap.
  43 * Swapcache cleaning is allowed to proceed even if swapcache is disabled.
  44 * sound - Port FreeBSD sound system to DragonFly.
  45 * sound - Add haswell support.
  46 * sound - Add ALC283 support.
  47 * sound - Add Acer C720 support.
  48 * sound - make device cloning work for multiple app access.
  49 * pxeboot - workaround some BIOS breakage.
  50 * usb-u4b - synchronize from FreeBSD as-of March 2015.
  51 * Refactor kernel message buffer (dmesg) code to fix lost text.
  52 * Fix panic in situations where a chroot is broken.
  53 * Fix O_CLOEXEC race in open() and fhopen().
  54 * Add pipe2() system call.
  55 * Add chflagsat() system call.
  56 * Refactor bdirty() handling to fix possible fsync races.
  57 * Add cpu C-state ACPI parsing and settings.
  58 * Add coretemp - sensor framework for core cpu temps.
  59 * Add memtemp - sensor framework for dram temps.
  60 * ECC support module and sensor framework.
  61 * Ext2fs code cleanup.
  62 * Tmpfs code cleanup.
  63
  64 ### Graphics
  65
  66 Significant progress continues in the drm (graphics) subsystem, with full acceleration (2D, 3D) supported on most Intel and some AMD GPUs.
  67
  68 The kernel drm code has been partially updated to Linux 3.14 in order to follow the evolution of the i915 and radeon drivers.
  69
  70 Many Linux programming interfaces and data structures have been implemented in order to make the drm code and its drivers run with as few modifications as possible. From the point of view of the graphics subsystem, the DragonFly kernel can thus be considered a BSD-licensed implementation of Linux.
  71
  72 DragonFly now has an experimental KMS (frame buffer) console.  Putting 'kern.kms_console=1' in /boot/loader.conf and either starting X or just loading the i915kms or radeonkms module enables support.
  73
  74 Backlight control is also generally available for i915 and radeon, useful for laptops.
  75
  76 #### i915
  77
  78 The drm/i915 driver has been updated to the Linux 3.14 version, bringing among other things support for Broadwell GPUs (but without acceleration for now).
  79
  80 * Most GEM code paths are now similar to the Linux ones, increasing stability and performance. This change has been greatly helped by the study of the OpenBSD code.
  81 * Many bug fixes. The driver is now more robust and handles GPU hangs better.
  82 * Power savings and framebuffer compression are now enabled by default, depending on the GPU family used.
  83 * Power management has generally been greatly improved
  84 * HDMI 4K monitors are now supported, as well as 3D/stereo displays
  85 * 10-bit color displays should now work out of the box
  86 * Monitor hot-plugging support has been improved and should now be more robust
  87 * 2D, 3D acceleration up through the Haswell chipsets now stable.
  88 * New members of the Haswell GPU family are now supported
  89 * Initial support for Broadwell GPUs (without acceleration)
  90 * Frequency changes and overclocking greatly improved on Sandy-Bridge to Haswell
  91 * The giant 128MB cache is now enabled when available on Haswell GPUs
  92 * The VECS engine is now enabled on Haswell GPUs and can be used by libva for video post-treatment tasks.
  93
  94 #### radeon
  95
  96 The drm/radeon driver has been updated to the Linux 3.11 version. The most important things this change brings are:
  97
  98 * Richland APUs support
  99 * Oland, Hainan and CIK chip family support
 100 * hdmi sound support (still experimental)
 101 * power savings improvements
 102
 103 It is also now possible to read temperature sensor information.
 104
 105 ### Networking
 106
 107 * Emx errata fixes for multi-TX queues.
 108 * Fix improper multicast setup for ig_hal.
 109 * Numerous ipv6 fixes and features.
 110 * Remove ipv4->ipv6 spoofing feature (no longer useful).
 111 * e1000 (em, emx, ig_hal) - sync w/intel em-7.4.2.
 112 * if_bridge improvements.
 113 * mountd now properly supports IPV6.
 114
 115 ### Packet Filter (pf)
 116
 117 * ipfw3 - Ported from FreeBSD (called ipfw2 in FreeBSD)
 118 * if_lagg improvements.
 119
 120 ### Mobile devices
 121
 122 * Synchronize 80211 infrastructure with FreeBSD.
 123
 124 ### Userland
 125
 126 * Many manual page cleanups.
 127 * date -R (RFC 2822 date and time output format).
 128 * patch - add dry-run alias.
 129 * sed - add unbuffered output option (-u)
 130 * camcontrol -b for camcontrol devlist op.
 131 * blacklist support removed from ssh (EOL for that old deian bug).
 132 * A simple in-base-system sshlockout, now uses PF table instead of IPFW.
 133 * tail -q (quiet mode removes filename headers).
 134 * Add 'idle', 'standby' and 'sleep' directives.
 135 * Fix seg-fault in jls.
 136 * Add 'ifconsole' option to /etc/ttys to enable serial ports only if designated as the console.
 137 * rtld-elf - Save/restore fp scratch regs for dynamic linker.
 138 * rtld-elf - minor bug fixes, synced with FreeBSD
 139 * powerd enhanced.
 140 * Major version updates for many dports.
 141 * Fix a resource leak in libc/db and a memory leak in libc/regex.
 142 * Ssh now correctly sets xauth's path.
 143 * libm augmented by FreeBSD (6 functions) and NetBSD (16 complex functions)
 144 * No more GNU Info pages provided on system
 145 * symbol versioning activated on 7 libaries: z, ncurses, lzma, edit, archive, md, bz2
 146
 147 ### Various tools have been upgraded in the base system:
 148
 149 * openssh 6.7p1.
 150 * file 5.22.
 151 * ftp 1.205 from netbsd.
 152 * sh - sync to FreeBSD d038ee76 (mostly fixes that effect poudriere).
 153 * mdocml 1.13.1.
 154 * byacc 2014-10-06
 155 * less 471
 156 * mpc 1.0.3 (internal)
 157 * bmake 2014-11-11
 158 * binutils 2.25 (primary)
 159 * GCC 5.1.1
 160 * OpenSSL 1.0.1o
 161
 162 ### Removed from the base system:
 163 * GCC 4.4
 164 * Sendmail 8.14
 165 * Binutils 2.21
 166 * texinfo 4.13
 167
 168 ### HAMMER improvements
 169
 170 * extensive code and documentation cleanups
 171 * huge number of minor fixes
 172 * most issues fixed were only visible on dedicated file servers under high loads
 173 * new "hammer abort-cleanup" command added
 174 * NFS export of slave filesystems is now possible
 175
 176 ### Other improvements
 177 * Boot menu refreshed - color by default - new Blue Fred logo added and displayed by default
 178 * Building mechanism improved (more parallelism - world and kernel, avoid rebuilding major libraries by changing dependency requirements, add missing start/completion messages on buildworld, buildkernel, make stage4 use recently built rpcgen instead of host rpcgen, don't build unused linker in ctools stage)
 179 * GCC50 base compiler embedded DT_RUNPATH rather than DT_RPATH (as has been done previously) in built executables.  The dynamic linker reacts differently when DT_RUNPATH is present; it will check LD_LIBRARY_PATH before the rpath in that case.
 180
 181 ### Hammer2 Status
 182
 183 Hammer2 is not ready for release but progress continues apace.  The core non-clustered code is about 95% operational for single-image operation.  This includes all standard frontend operations, snapshots, compression, and the bulk free scan.
 184
 185 [In the words of Matthew Dillon]:
 186
 187 Work is progressing on the clustering piece.  Since the clustering is really the whole point, I am not going to release HAMMER2 until it is operational.
 188
 189 Recent developments are as follows:
 190
 191 I buckled under and bumped the blockref descriptor from 64 bytes to 128 bytes.  This was needed to properly support per-directory quota and inode/data-use statistics but it also has the fringe benefit of allowing up to 512-bit check codes to be used.  The quota management is an extremely powerful tool in HAMMER2 so I deemed it worth doing despite the added bloat.  I could not implement the fields in the inode due to the presence of indirect blocks without significantly adding to the complexity of the software which is why it had to go into the blockref.
 192
 193 The use of very large check codes makes non-verified de-duplication for non-critical data possible.  (Non-verified dedup is de-duplication based only on the check code, without validating the actual data content, so collisions are possible where the data does not match.  However, it also means the de-duplication can be done several orders of magnitude more quickly needing only a meta-data scan with no data I/O).  This is the only sort of dedup that really works well on insanely huge filesystems.
 194
 195 The 1KB H2 inode is able to embed 512 bytes of direct data.  Once file data exceeds 512 bytes, that area in the inode is able to embed up to 4 blockrefs (it used to be 8), representing up to 4 x 64KB = 256KB of file data.  Since HAMMER2 uses 64KB logical blocks (actual physical blocks can be smaller, down to 64 bytes), the blockref overhead is at worst 128 bytes per 64KB or 0.2% of storage.  Hammer2 itself implements a radix tree for the block table.  Larger block sizes are possible but not convenient due to buffer-cache buffer limitations and the need to calculate and test check codes.
 196
 197 My original attempt to implement the clustering mechanic was to use the calling context and both asynchronous locks and asynchronous I/O all in-context acting on all cluster nodes to prevent stalls due to dead or dying nodes.  It had the advantage of being very parallel (concurrency scales with process threads).  But this quickly became too complex algorithmically and I've given up on that approach.  The new approach is to replicate the request from the user thread to multiple kernel threads, one per cluster node, which then execute the operation on each node synchronously (much easier), independent of the user process, and then aggregate/consolidate the results back to the user process.  The user process will be able to detach the operation and return the instant it gets a definitive result.  This means that stalled or dying nodes will not slow down or stall the frontend VOP.  The kernel node threads themselves can be multiplied out for additional concurrency.
 198
 199 It should be noted that frontend operations which operate on cached data will be able to complete in-context and will not have to issue replicated requests to these kernel threads.  This includes core inode meta-data and, most especially, read or write operations for data already cached in the VM page cache / buffer cache.