- DragonFly's Major Features List
Please keep in mind that major modifications have been made to nearly the entire DragonFly kernel relative to the original FreeBSD-4.x fork. Significant changes have been made to every kernel subsystem, as a consequence this list is constrained to the largest, most user-visible changes unique to DragonFly.
The scheduler abstraction has been split up into two layers. The LWKT (Light Weight Kernel Thread) scheduler is used by the kernel to schedule all executable entities. The User Thread Scheduler is a separate scheduler which selects one user thread at a time for each cpu and schedules it using the LWKT scheduler. Both scheduler abstractions are per-cpu but the user thread scheduler selects from a common list of runnable processes.
The User Thread Scheduler further abstracts out user threads. A user process contains one or more LWP (Light Weight Process) entities. Each entity represents a user thread under that process. The old rfork() mechanism still exists but is no longer used. The threading library uses LWP-specific calls.
The kernel memory allocator has two abstracted pieces. The basic kernel malloc is called kmalloc() and is based on an enhanced per-cpu slab allocator. This allocator is essentially lockless. There is also an object-oriented memory allocator in the kernel called objcache which is designed for high volume object allocations and deallocations and is also essentially lockless.
DEVFS - is the DragonFly device filesystem. It works similarly to device filesystems found on other modern unix-like operating systems. The biggest single feature is DEVFS's integration with block device serial numbers which allows a DragonFly system to reference disk drives by serial number instead of by their base device name. Thus drives can be trivially migrated between physical ports and driver changes (base device name changes) become transparent to the system.
VKERNEL - DragonFly implements a virtual kernel feature for running DragonFly kernels in userland inside DragonFly kernels. This works similarly to Usermode Linux and allows DragonFly kernels to be debugged as a userland process. The primary use is to make kernel development easier.
NFS V3 RPC Asynchronization - DragonFly sports a revamped NFSv3 implementation which gets rid of the nfsiod threads and implements a fully asynchronous RPC mechanism using only two kernel threads. The new abstraction fixes numerous stalls in the I/O path related to misordered read-ahead requests.
HAMMER is the DragonFly filesystem, replacing UFS. HAMMER supports up to an Exabyte of storage, implements a fast UNDO/REDO FIFO for fsync(), recovers instantly on boot after a crash (no fsck), and implements a very sophisticated fine-grained historical access and snapshot mechanism. HAMMER also sports an extremely robust streaming, queueless master->multiple-slave mirroring capability which is also able to mirror snapshots and other historical data.
All non-temporary HAMMER filesystems in DragonFly automatically maintain 60 days worth of 1-day snapshots and 1-day worth of fine-grained (30-second) snapshots.
HAMMER is designed to accommodate today's large drives.
A null or loop-back filesystem is common to a number of operating systems. The DragonFly null filesystem is quite a different animal. It supports arbitrary mount points that do not loop, a problem on other operating systems, making it extremely flexible in its application. It is also extremely fast and reliable, something that few other operating systems can claim of their null filesystem layers.
Originally a NetBSD port the guts have been radically adjusted and carefully tuned to provide a low-contention read path and to directly tie the backing store to the VM/paging system in a way that treats it almost like normal memory. Only memory pressure will force tmpfs data pages into swap.
TMPFS replaces MFS and MD (for post-boot use).
DragonFly has a device mapper target called dm_target_crypt (compatible with Linux' dm-crypt) that provides transparent disk encryption. It makes best use of available cryptographic hardware, as well as multi-processor software crypto.
DragonFly fully supports LUKS (cryptsetup) and TrueCrypt as disk encryption methods. tcplay, is a free (BSD-licensed) 100% compatible TrueCrypt implementation built on dm_target_crypt.
This DragonFly feature allows SSD-configured swap to also be used to cache clean filesystem data and meta-data. The feature is carefully managed to maximize the write endurance of the SSD. Swapcache is typically used to reduce or remove seek overheads related to managing filesystems with a large number of discrete inodes. DragonFly's swap subsystem also supports much larger than normal swap partitions. 32-bit systems support 32G of swap by default while 64-bit systems support up to 512G of swap by default.
Variant (context-sensitive) symlinks give users, administrators and application authors an extremely useful tool to aid in configuration and management. Special varsym variables can be used within an otherwise conventional symbolic link and resolved at run-time.
Processes under DragonFly may be "checkpointed" or suspended to disk at any time. They may later be resumed on the originating system, or another system by "thawing" them.
DragonFly has its own from-scratch time daemon. After pulling our hair out over the many issues with open source time daemons we decided to write one ourselves and add new system calls to support it. DNTPD uses a double staggered linear regression and correlation to make time corrections. It will also properly deal with network failures (including lack of connectivity on boot), duplicate IPs resolved by DNS, and time source failures (typically 1 second off) when multiple time sources are available. The linear regression and correlation allows DNTPD to make rough adjustments and frequency corrections within 5 minutes of boot and to make more fine-grained adjustments at any time following when the linear regression indicates accuracy beyond the noise floor.
The DragonFly Mail Agent is a bare-bones (though not so bare-bones any more) mail transfer and mail terminus SMTP server which provides all the functionality needed for local mail delivery and simple remote mail transfers. A more sophisticated MTA can then be thrown onto an installed system via DPorts.