Master release schedule changes, major feature list - September 2009

[Matthew Dillon]

    We are going to be shifting our master release schedule 2 months forward.
    This is being done for several reasons.  We will be releasing in
    September and March instead of July and January.

    This will give us a bit more time to sync up with pkgsrc quarterlies and
    also moves our releases out of the dead months (high summer and
    christmas) and into months where developers are more active.

    So we will be releasing 2.4 in September rather then this month.  There
    will be a lot of stuff in 2.4, and hopefully considerbly more by the
    time the release actually rolls around:

    * Jordan's AMD64 work: 64 cpu bit support for UP, hopefully 64 bit
      support for SMP.  Probably not 32 bit emulation under 64 bits by
      September though.

    * Alex's work: DEVFS.  I believe sufficient progress will be made in the
      next two months to make it useable.

    * Aggelos's NETMP work.

    * Sephe's network driver work and SMP work.

    * Sascha's installer improvements making a BOOT + HAMMER setup the
      default installation method.  Also fdisk can now be used on drives
      larger then 2TB and the kernel recognizes maxed-out fdisk parameters
      so disklabel64 will recognize the actual size of the disk if the fdisk
      slice is maxed out.

    * Additional work by me to help integrate serial number support into
      DEVFS (once Alex gets a little bit further on it), and adopting
      OpenBSD's /etc/devtab methodology.

      The serial number work is going to become *VERY* important as HAMMER
      development moves into the cluster-FS phase.  At that point drives
      will be able to exist anywhere on the network.  Even without that
      we have a real need to start addressing drives by serial number simply
      due to the fact that one can trivially connect many drives to the
      motherboard now via port multiplier enclosures.  Counting on the
      /dev/daXXX enumeration is simply not reliable.

    * 2.4 will feature a complete pkgsrc rebuild using libc.so.7.  The
      2.3 development branch will also get this pkgsrc build in the next
      few days (if not today).  Thanks to Justin and Hasso.

    * We will officially deploy the AHCI and the SILI driver.  These drivers
      are working now for most MBs but there are still a few open bug reports
      with certain chipsets and devices.  For people with AHCI-capable
      chipsets on their motherboards, or with Sili 3132 boards (other Silicon
      Image parts will be added as well), the new disk drivers feature
      NCQ, hot-swap, port-multiplier, and hot-swap targets behind the
      port-multiplier.

    * Hasso's pkgsrc work and related improvements in libthread_xu to build
      more packages out of the box.

    * My HAMMER work, improving directory tree traversal times, bug fixes,
      reduced stress on the machine when reblocking the disk, and so forth.

    * Lots of bug fixes improving stability.


				More on BOOT+HAMMER

    All the BSDs have been struggling with how to boot into new filesystems,
    but more to the point they've been struggling with issues of booting into
    redundant drive setups (RAID arrays of various sorts).

    What I have decided is that the most flexible way to deal with booting
    is to adopt a Linux-like methodology where a small UFS BOOT partition
    on 'a' is created containing the boot loader, kernel, and modules,
    and the ROOT partition will be placed on 'd'.  This also allows the
    swap partition to remain on the outer cylinders of the disk in the 'b'
    partition.

    This gives us a very flexible basis for mounting the root partition,
    including being able to more conveniently use software raid features
    and more complex arrangements for the root partition and other mounts.

    DragonFly will not officially support booting from BIOS-fakeraid.  IMHO
    my opinion is that anyone who needs *real* redundancy for the boot loader
    and kernel should simply boot from a SATA SSD (SATA based Solid State
    Drive).  SATA SSDs have the same MTBF as the motherboard, so there's no
    point creating a redundant SSD setup.  One works fine.  This might be
    perceived as a negative but I consider it reality.  One can't even
    safely migrate the physical disks from a fake-raid setup to another
    machine.

    On the plus side, while our software RAID support is still basically just
    vinum, one fringe benefit of using HAMMER is that software RAID is
    actually a lot easier to implement because it does not have to be
    transactional.  For example, it would be ok for a mirror to become
    inconsistent due to a crash/reboot (though not during the course of
    normal operation).  HAMMER's recovery on reboot will effectively 
    resynchronize the needed bits when it runs its UNDO.  So while we are
    a bit behind on the technology in this area HAMMER actually gives us
    a considerable advantage in developing soft-raid systems that are
    reliable.

    All of this will eventually be combined with the serial number support
    and network disk and upcoming cluster-FS work.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>