HAMMER2 emergency space mode

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!

HAMMER2 corruption bug and fix

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.



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?

Upgrade results, bonus for dragonflybsd.org

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.