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’.
Mount and HAMMER2 labels
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.
Hammer and PFS notes
Simple fix for speed
I always attributed speed issues to writing transaction history, but: Matthew Dillon discovered HAMMER was repeating itself when writing to disk. Fixing that issue doubled write speed. This fix is in 4.6 and the upcoming release.
Good news for multiple processors
Matthew Dillon has made a number of locking improvements, that speeds up performance on systems with multiple processor. Here’s his commit with some numbers. Note that he’s testing with these built-in utilities. This probably helps multiple cores too, and some attention is shown to Hammer, too.
Zeroing does nothing
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.
Buildworld for -current users
If you are on DragonFly-current, AKA DragonFly 4.7, make sure to perform a full buildworld on your next upgrade. Tomohiro Kusumi changed a Hammer ioctl, and the buildworld is needed to keep everything in sync.
Reminder: move your Hammer cleanup
A useful tip: if your DragonFly machine isn’t usually on 24/7 (e.g. a laptop, not a server), you should move your Hammer cleanup from 3 AM to sometime when the computer is normally on.
Hammer2 major changes
Hammer2 now has inode indexing, which Matthew Dillon was avoiding while trying to create more efficient hardlink support. The result is now with that problem solved, more updates can come in: NFS support, mtime updates, output changes, code removal, and lots of other changes, not all of which I’m even linking.
What’s that @@?
Tomohiro Kasumi wrote a lengthy explanation of what “@@” means, in the context of the Hammer file system. It acts as a sort of signifier for each actual Hammer pseudo-file-system, since it’s possible to null-mount these anywhere in DragonFly, under all sorts of names. Don’t trust my summary, though – read his.
The rescue undo
Did you know there’s a rescue image, created with crunchgen, in DragonFly? If your system can boot to single-user mode, you can use it to at least manipulate data on disk – it includes mined as a simple small editor. (Since vi assumes /usr is mountable.) This rescue image now includes undo, so you can back out changes on a Hammer volume.
Hammer and FreeBSD
Tomohiro Kusumi would like to port Hammer (1) to FreeBSD, as noted in this bug discussion. It’s not even begun to happen, but if you can contribute, please do.
More Hammer fixups
Tomohiro Kusumi has been creating a near-constant stream of bugfixes and cleanups to Hammer for quite some time. I don’t often link to it, because they are incremental improvements and hard to linkblog, so to speak. In an effort to make up for this deficit, I do want to draw attention to his two recent commits: “Make hammer commands print root volume path“, and “Print volume list after volume-add|del“. Small changes, but this is what makes complex systems usable.
Hammer not show
The ‘hammer show’ command can be used to dump the B-Tree structure of a Hammer volume, and CRC errors can be spotted. It’s rare that anyone would need it, but if you do, this dumped information will include file hierarchy information.
If that makes you a bit nervous to repost any of that information when talking about it in public, Tomohiro Kusumi has added an ‘obfuscate’ option to ‘hammer show’ that does just that – it hides path information from the debug output.
Checking HAMMER volumes for health
No atime in Hammer
Hammer now defaults to ‘noatime’, meaning the date and time of last access are not updated on every file action. Note that creation and modification date and time are still recorded. This will help with speed and disk activity.
This may cause a problem with any software expecting this to change – mutt, possibly? We will find out. This change was done after the 4.4 branch, so it’s not in the current release of DragonFly.
Hammer2 mountall and info directives
Matthew Dillon has added two Hammer2 directives – ‘info’ and ‘mountall’. See his commit message for a explanation of each. This predates the 4.4 branch, so it’s available in the current release. The usual caveat applies: Hammer2 is for development only; don’t use this to store data you want to use.
Hammer 2 and xlinks
I have a huge backlog of things to post, so this is originating from the 17th: Matthew Dillon has been working for some time on hardlinks and Hammer 2. Hardlinks are the same file, presented in multiple places. This can be a problem when your filesystem keeps infinite, writable snapshots. The solution he just commited is called ‘xlink’ and the commit message has details.
No more dsched
The disk scheduler apparatus in DragonFly has been removed. This may not affect you much, since alternate scheduling setups were never utilized much with it. It may fix some rare Hammer cleanup issues, though, and you may need to adjust your custom kernel config, if you have one.
HAMMER2 root mounts and live dedup too
HAMMER2 recently gained the ability to be used as the root mount for your DragonFly system. Live deduplication of data is also now possible, which means fast copy operations, less space used, and no need to wait for an overnight batch process to do it. If you want to try it, you need a bleeding edge DragonFly system and the WANT_HAMMER2 option. It’s still not ready for production use, so don’t try it with any data you want to keep.