* major new filesystem (Hammer2)
* OpenBSD might even adopt Hammer2 has a replacement of it's legacy filesystem 
* huge work on network performance. DragonflyBSD is agrubably the fastest BSD for network intensive tasks 
* IPFW has been rewritten to be multi-threaded which has resulted in huge performance improvements 
To also give context as to what Dragonfly BSD is, DragonFly BSD was forked from FreeBSD 4.8 in June of 2003, by Matthew Dillon over a differing of opinion on how to handle SMP support in FreeBSD. Dragonfly is generally consider as having a much simpler (and cleaning) implementation of SMP which has allowed the core team to more easily maintain SMP support; yet without sacrificing performance (numerous benchmarks demonstrate that Dragonfly is even more performant than FreeBSD ).
The core team of Dragonfly developers is small but extremely talented (e.g. they have frequently found hardware bugs in Intel/AMD that no one else has found in the Linux/BSD community ). They strive for correctness of code, ease of maintainability (e.g. only support x86 architecture, design decisions, etc.) and performance as project goals.
If you haven't already looked at Dragonfly, I highly recommend you to do so.
Does anyone here know how/if this cheaper-but-slower kind of redundancy is addressed in DflyBSD?
Gotta love an undated presentation that compares DragonFlyBSD version 719bf70a37139bc3bedc84ab0975df7107155714 with FreeBSD version r314268. It can't be super old because Linux 4.9 was released in Dec 2016, but still.
So around 2017-02-25
btrfs is fighting much the same battle for adoption and frankly has a much better chance of seeing success since it's not tied to a niche OS like DragonflyBSD. ZFS-on-Linux finally being available+stable was a massive milestone in terms of adoption since it finally broke away from the tight ties to the Solaris/BSD ecosystems.
So yeah, regardless of how amazing Hammer is, I do have to ask whether there's really space for another filesystem out there. Kudos to Dillon for going ahead and doing it anyway though ;)
Because it uses the BSD license, it can be adapted to work in more mainstream OSes without problems. If OpenBSD would adopt it for example, it would really help it to cover a few more use cases. I'd also expect some efforts from NetBSD, FreeBSD and Linux. Even Apple and Microsoft could adopt Hammer2 and just use the original source code, although they have no particular reason to do so.
Filesystems are not really an area of the system that is amenable to flavor-of-the-month and running v1.0 of a new codebase doesn't sound appealing.
They haven't seem to have any problems running a v1.0 filesystem and I have to imagine way more people are now running APFS then ZFS ever.
As an aside, this is one of the several unbelievably slick updates Apple has pulled off in its history, including:
- the switch to 32-bit clean addresses only (which was probably the most painful switch Apple ever did!) in System 7.6
- the switch to PowerPC (which caused fewer problems than the 32-bit clean switch!)
- the switch to Mac OS X
- the switch to Intel
- the switch to 64-bit on desktop
- the switch to 64-bit on iOS
Microsoft, (in most cases rightly) vaunted for backwards compatibility has had horrific snafus such as DOS 5 being the first version of DOS whose RESTORE program could read BACKUP files from the previous version of DOS.
(It's also worth noting that NeXT itself managed to support four runtime architectures with "quad fat binaries".)
I suppose that meant doing a small install in some virtual disk? I can't think apple put at risk anyone's data.
But then, that would not have been the same as actually testing the real hardware interface, would it?
More relevant to the parent, though: the upgrade to APFS happened in iOS 10.3, not iOS 11. So whatever bug you may have had with iOS 11 probably have nothing to do with the file system.
Should I go on?
ReiserFS springs to mind, but what other one-man-show filesystems have there been?
It is strange. Linux users would do anything for ZFS and BSDs are moving away from it.
You can build a new initrd - cd into src/share/initrd/sbin, add it to the makefile, type 'wmake install' I think, and you may be good. I am guessing because I don't have an encrypted disk to test.
Otherwise, wait and there will be an updated 5.01 image soon, I'm sure - the recent KRACK vulnerability will prompt that, if nothing else.
FreeBSD on the laptop has decent support, and in a couple of weeks you will learn about initrd etc. to be able to work with DragonflyBSD.
If you want to learn more about system internals, you might want to learn how to use bhyve (FreeBSD's awesome hypervisor) on FreeBSD.
By trying to use bhyve you will learn how to extract the kernel from an img build, load it etc.
Have fun and good luck on your studies!
Are these advantages so significant that it is worth it?
Of course it's worth it. It's significantly faster and better