An interesting thought: since HAMMER2 is intended to be a multi-master file system, it has to figure out – and quickly – which is the most up to date versions of any given file. That means you could have multiple versions of a file existing at the same time until that decision is made. That wouldn’t be visible from a user perspective.
It’s apparently possible to get a panic by yanking a HAMMER2 disk out of your system, which is only likely when using a USB thumb drive, formatting it to HAMMER2, and not bothering to unmount it. Anyway, that poorly-described-by-me problem is fixed.
There’s an odd bug in ipfw that is now fixed in DragonFly 6.2/6.3. If you are using ipfw and adding networks and hosts in a specific order, the netmask will be set wrong.
There’s also a problem with the overnight bulkfree cleanup in Hammer that’s had various attempts to fix it over time – it’s now really truly fixed. It mattered only if you had an extremely large number of inodes – 100000000 or so,
Matthew Dillon wrote up an explanation for both.
It may be because I am a nerd but I enjoy reading detailed explanations of bugfixes like this one for HAMMER2. This fix is present in the 6.2 release, of course.
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)