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 * Misc minor hammer fixes.
  62 * Hammer code cleanup.
  63 * Ext2fs code cleanup.
  64 * Tmpfs code cleanup.
  65
  66 ### Graphics
  67
  68 Significant progress continues in the drm (graphics) subsystem, with full acceleration (2D, 3D) supported on most Intel and some AMD GPUs.
  69
  70 The kernel drm code has been partially updated to Linux 3.14 in order to follow the evolution of the i915 and radeon drivers.
  71
  72 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 as a BSD-licensed implementation of Linux.
  73
  74 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.
  75
  76 #### i915
  77
  78 * 2D, 3D acceleration up through the Haswell chipsets now stable.
  79 * Backlight control is available generally for i915 and radeon, useful for laptops.
  80
  81 #### radeon
  82
  83 The drm/radeon driver has been updated to the Linux 3.11 version. The most important things this change brings are:
  84
  85 * Richland APUs support
  86 * Oland, Hainan and CIK chip family support
  87 * hdmi sound support (still experimental)
  88 * power savings improvements
  89
  90 It is also now possible to read temperature sensor information.
  91
  92 ### Networking
  93
  94 * Emx errata fixes for multi-TX queues.
  95 * Fix improper multicast setup for ig_hal.
  96 * Numerous ipv6 fixes and features.
  97 * Remove ipv4->ipv6 spoofing feature (no longer useful).
  98 * e1000 (em, emx, ig_hal) - sync w/intel em-7.4.2.
  99 * if_bridge improvements.
 100 * mountd now properly supports IPV6.
 101
 102 ### Packet Filter (pf)
 103
 104 * ipfw3 - Ported from FreeBSD (called ipfw2 in FreeBSD)
 105 * if_lagg improvements.
 106
 107 ### Mobile devices
 108
 109 * Synchronize 80211 infrastructure with FreeBSD.
 110
 111 ### Userland
 112
 113 * Many manual page cleanups.
 114 * date -R (RFC 2822 date and time output format).
 115 * patch - add dry-run alias.
 116 * sed - add unbuffered output option (-u)
 117 * camcontrol -b for camcontrol devlist op.
 118 * blacklist support removed from ssh (EOL for that old deian bug).
 119 * A simple in-base-system sshlockout, now uses PF table instead of IPFW.
 120 * tail -q (quiet mode removes filename headers).
 121 * Add 'idle', 'standby' and 'sleep' directives.
 122 * Fix seg-fault in jls.
 123 * Add 'ifconsole' option to /etc/ttys to enable serial ports only if designated as the console.
 124 * rtld-elf - Save/restore fp scratch regs for dynamic linker.
 125 * rtld-elf - minor bug fixes, synced with FreeBSD
 126 * powerd enhanced.
 127 * Major version updates for many dports.
 128 * Fix a resource leak in libc/db and a memory leak in libc/regex.
 129 * Ssh now correctly sets xauth's path.
 130 * libm augmented by FreeBSD (6 functions) and NetBSD (16 complex functions)
 131 * No more GNU Info pages provided on system
 132 * symbol versioning activated on 7 libaries: z, ncurses, lzma, edit, archive, md, bz2
 133
 134 ### Various tools have been upgraded in the base system:
 135
 136 * openssh 6.7p1.
 137 * file 5.22.
 138 * ftp 1.205 from netbsd.
 139 * sh - sync to FreeBSD d038ee76 (mostly fixes that effect poudriere).
 140 * mdocml 1.13.1.
 141 * byacc 2014-10-06
 142 * less 471
 143 * mpc 1.0.3 (internal)
 144 * bmake 2014-11-11
 145 * binutils 2.25 (primary)
 146 * GCC 5.1.1
 147 * OpenSSL 1.0.1o
 148
 149 ### Removed from the base system:
 150 * GCC 4.4
 151 * Sendmail 8.14
 152 * Binutils 2.21
 153 * texinfo 4.13
 154
 155 ### Other improvements
 156 * new "hammer abort-cleanup" command added to HAMMER
 157 * Boot menu refreshed - color by default - new Blue Fred logo added and displayed by default
 158 * 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)
 159 * 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.
 160
 161 ### Hammer2 Status
 162
 163 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.
 164
 165 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.
 166
 167 Recent developments are as follows:
 168
 169 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.
 170
 171 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.
 172
 173 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.
 174
 175 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.
 176
 177 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.