It used to be that if you had a HAMMER2 volume and ran low on space, snapshotting would stop so that you didn’t completely fill the disk. Now, thanks to Francis GUDIN, snapshots continue to roll forward and discard older ones to keep disk usage constant. It won’t fix the low disk space issue, but snapshots will stay up to date. It’s in 6.0 too.
Many, many times over the years I have tried answering problems with “… and maybe something’s wrong with the RAM?”, which is always possible but not always probable. For once, it’s really what happened in this story of strange HAMMER2 errors.
Matthew Dillon’s fixed a possible deadlock in HAMMER2, plus some optimizations that I can’t quantify, but are fun to read about.
HAMMER2 just became a little more DWIM: the pfs-list and pfs-delete directives will now look across all mounted filesystems, not just the current directory’s mount path. pfs-delete won’t delete any filesystem name that appears in more than one place, though.
If you’ve been following HAMMER2 for some time, these questions and answers will not be new to you – but they are useful notes all the same.
As anyone who has been running HAMMER1 or HAMMER2 has noticed, snapshots and copy on write and infinite history can eat a lot of disk space, even if the actual file volume isn’t changing much. There’s now an ‘emergency mode‘ for HAMMER2, where disk operations can happen even if there isn’t space for the normal history activity. It’s dangerous, in that the normal protections against data loss if power is cut go away, and snapshots created while in this mode will be mangled. So definitely don’t leave it on!
If you have a whole lot of I/O on a HAMMER2 system, this change will help. This is I assume an outgrowth of dsynth testing, cause that causes many, many threads to be reading and writing.
HAMMER2 is Copy on Write, meaning changes are made to copies of existing data. This means operations are generally atomic and can survive a power outage, etc. (You should read up on it!) However, there’s now a fsck command, useful if you want a report of data validity rather than any manual repair process.
This slipped in just before the 5.6 release, and I thought I had already noted it: DragonFly now defaults to HAMMER2 for disks during install, instead of HAMMER1.
Matthew Dillon’s committed some performance work for HAMMER2, dealing with write-clustering. I don’t have statistics to note, so here’s the commit message.
It’s always helpful to see other people’s questions and answers; in this case it’s a conversation about HAMMER2 snapshots and how to manage them. (Follow the thread)
It’s possible to have data corrupted on a HAMMER2 volume during a specific combination of a bulkfree operation and a lot of writing to disk. Matthew Dillon has a potential fix already. As he announced, it’s scheduled to go into 5.4 this weekend. It’s a rare bug, but if you want to check for it, look for CHECK FAIL entries in /var/log/messages.
And because every cloud has a silver lining: some not-yet-quantified performance improvements.
This week’s BSD Now covers assembly on OpenBSD, games on FreeBSD, and disk space on DragonFly.
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.