|
The original plan was a SSI, single-system-image operating system, where one cohesive system could span across multiple physical machines. It's quite a long ambitious plan, but it's still up on the project's history page[1]: > DragonFly BSD has been going through rapid and ever increasing development since the fork. One of the important works included the simplification and general cleanup of the majority of the kernel subsystems. This work was originally intended to support single system image clustering, but has had the effect of making the kernel much more reliable, understandable and easily maintainable. One of the fundamental synchronization concepts that DragonFly uses throughout the kernel, the token, lends itself directly to ease of maintenance and understandability of the kernel. There's been plenty of neat off-shoot advantages DragonflyBSD has gained along this quest. Great great scalability has been notable; the core coherency construct, the serializing token, targets reducing locking in the system & potentially allows scale-out into SSI. DragonflyBSD has some really cool tricks, like being able to run virtual kernels- running a kernel as a process, for "jail" or just kerneldev reasons. Still it's impossible to mention DragonflyBSD without mentioning it's filesystem, HAMMERFS, and now HAMMERFS2, which is a great Copy-on-Write & snapshotted fs intended for radical scale out, & ultimately, clustering, where multiple machines can cohesively contribute & operate a single filesystem together, with pooled resources. There is already a good bit of quorumed clustering support in HAMMERFS2. > The HAMMER filesystem is also intended to serve as a basis for the clustering and other work that makes up the second phase of the project. There's a StackOverflow question talking to DragonflyBSD as a SSI[2] as well, which mainly cites the same History page, but also has some other links. [1] https://www.dragonflybsd.org/history/ [2] https://unix.stackexchange.com/questions/429464/dragonfly-bs... |