While it's not part of this week's DragonflyBSD 3.0
release, Matthew Dillon is currently designing the HAMMER2 file-system to succeed his original HAMMER creation in Dragonfly.
The HAMMER2 file-system has been under-development already, but Dillon doesn't expect for anything usable prior to July. While it may be usable this summer, he doesn't believe it will be until "well into 2013" when "the whole mess is implemented and even later before the clustering is 100% stable." This is the only project Matthew Dillon is said to be working on this year.
HAMMER2 has many more features over the first HAMMER file-system, but Matthew Dillon says its design will be a lot simpler.
HAMMER2 is fundamentally different from HAMMER1 in that it uses a copy-on-write block design over a B-Tree design in the original DragonflyBSD file-system. Some of the HAMMER2 highlights include:
- Writable snapshots support with any sub-directory being able to be snapshotted. "Snapshots show up in the super-root. It is possible to snapshot a subdirectory and then later snapshot a parent of that subdirectory... really there are no limitations here."
- Multiple roots support so that snapshots can be mounted.
- Incremental queueless mirroring / mirroring-streams.
- Support for multiple compression algorithms on a sub-directory tree and file basis.
- Copies support for redundancy
- HAMMER2 is designed to be cluster-able with a multi-master protocol design in the long-term.
- Support for hard-links plus all other standard file-system features.
- De-duplication support will be supported and automatic. There will also be non-verified de-duplication as an option on a file or sub-directory basis.
Full details on the DragonflyBSD HAMMER2 file-system plans can be found in this mailing list message
from earlier in the month.
From last year you can see original benchmarks of HAMMER compared to Btrfs and ZFS
Meanwhile, the start of some DragonflyBSD 3.0 benchmarks can be found on OpenBenchmarking.org