Tomohiro Kusumi’s offline HAMMER2 support continues, with ‘setcheck’ (check code) and ‘setcomp’ (compression type) support. See the hammer2(8) man page for what those options do.
You can now create, delete, and snapshot PFS on HAMMER2 even when the drive isn’t mounted; Tomohiro has added offline support.
You can now clean up, grow, and destroy HAMMER2 volumes, even when they are not mounted. There’s also an emergency mode, though I’m not clear on when you’d invoke it.
Predrag Punosevac has some notes on how he cleaned up some HAMMER drives and freed up half his disk space.
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.
xdisk is now being built by default, and libdmsg is able to encrypt/decrypt with a placeholder scheme.
Yes, this means you can mount remote Hammer2 disks as a block device. Read the man pages and remember this is experimental.
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.
Nelson H. F. Beebe posted links to two ACM articles; one about SSDs and the other about filesystem resilience. Matthew Dillon chimed in with his thoughts specifically on HAMMER2.
Matthew Dillon’s fixed a possible deadlock in HAMMER2, plus some optimizations that I can’t quantify, but are fun to read about.
HAMMER2 now has a ‘growfs’ directive, so if there’s room in the partition, you can expand your HAMMER2 volume to fit. Related: gpt(8) and disklabel(8) now have similar options. fdisk(8) does also.
The first version of HAMMER took automatic snapshots, set within the config for each filesystem. HAMMER2 now also takes automatic snapshots, via periodic(8) like most every repeating task on your DragonFly system.
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.