For future edification: If you have HAMMER2 installed, the bulkfree operation will create console/dmesg activity even when nothing is wrong, to show operations are happening.
Matthew Dillon recently fixed a TRIM bug, where a TRIM command was being issued unconditionally, regardless of the mount flag, and duplicating the action if it was set normally. It’s fixed now. This would only have any significant slowdown on UFS, which means it would only affect installworld – the rest of your mounted volumes are HAMMER, right?
As part of a larger conversation about HAMMER, Matthew Dillon noted that he is planning to work on master-to-multiple-slave for HAMMER2, which would function similar to HAMMER1 mirror-stream.
Remember the upgrade for dragonflybsd.org machines? It completed, and it’s interesting to see that SSDs have become so easily available that “spinning rust” hard disk drives are only still useful for bulk storage, and even then probably not for much longer.
Another neat side effect: disk usage on developer system leaf.dragonflybsd.org was cut in half, thanks to HAMMER2 dedup/compression. It’s a ‘free’ half-terabyte.
These would be ‘In Other BSD’ links, but this isn’t Other BSD – It’s DragonFly:
- Towards a HAMMER1 master/slave encrypted setup with LUKS.
- Intro, Installation, and Fun with Hammer2.
I’m pulling a quote off of IRC to show some of the testing on HAMMER2, specifically as the background for this commit:
14:22 <@dillon_> ^^^ hammer2 bug, could reproduce it around once a day doing a continuous rm -rf on hardlinked snapshots. reproduced about once every 500 million directory entries or so
I am somewhat tickled by the notion that you might have a problem after deleting half a billion directory entries.
The regular maintenance scripts for HAMMER1 assume that it’s mounted at the time of cleanup. If you have them unmounted, they won’t go through that regular maintenance, but it’s easy enough to fix.
You could, if you are running DragonFly-current, create a vkernel using HAMMER2, and try out HAMMER2 even if your underlying disk is HAMMER1. Odd, but useful.
You can make them, but you can’t mount them. Tomohiro Kusumi’s note that mkfs_hammer2 works on Linux is of little wide practical use, but it’s a sign of progress to a larger goal.
Tomohiro Kusumi has made the userspace tools for HAMMER1 compilable on Linux, so you could create a HAMMER1 volume on a Linux system. No, it’s not the ability to read/write HAMMER1 in Linux, unfortunately – just some manipulation of volumes. I don’t know what his future plans are for HAMMER1|2 on Linux, if any.
Continuing my catchup on recent commits, there’s now a ‘version 7’ internal to HAMMER 1. It changes the CRC code to a faster version, but since this instruction isn’t used (yet), there’s no real world impact. Remember this for next time you want to run ‘hammer version-upgrade’.
If you’re mounting a HAMMER2 filesystem, you can refer to it by label instead of by device.
No, it’s not ready for use yet and I don’t have a date other than “when it’s done”, to preanswer the next questions.
This makes sense once you think about it: copy-on-write filesystems (like Hammer2 and ZFS and probably others) actually do nothing when “zeroing” out filespace.