DragonFly BSD Digest » Hammer

How low can you go? (with RAM and Hammer)

Justin Sherrill — Thu, 19 Jan 2012 21:41:55 +0000

Matthew Dillon has a very detailed commit message with changes to make sure Hammer will run overnight cleanups in situations as low as 256M of RAM. I think you can find that much RAM in breakfast cereal boxes these days.

How much RAM is too little?

Justin Sherrill — Mon, 02 Jan 2012 18:59:58 +0000

If you’re running DragonFly on a very low-end system, you may be wondering about memory requirements for Hammer. Hammer is much less RAM-hungry than ZFS, so it looks like you can get away with 128M, as long as you don’t mind the occasional error message. You can manually tweak settings for it if you like. 256M is plenty.

It still strikes me as odd to consider systems with less than 1G of RAM as “low-memory”. What rich times we live in!

Libhammer added

Justin Sherrill — Tue, 01 Nov 2011 02:23:01 +0000

Antonio Huete Jimenez’s ‘libhammer‘, a library to make various Hammer functions available to userland programs, has been added. It implements ‘hammer info’ only at this point, if I understand correctly.

A new Hammer presentation

Justin Sherrill — Wed, 26 Oct 2011 23:44:22 +0000

Francois Tigeot recently presented a set of slides about Hammer at a recent Irill conference. PDFs of the slides are available at his site, in English and French.

Quotas almost sort of working

Justin Sherrill — Fri, 19 Aug 2011 20:18:33 +0000

Francois Tigeot took an old Summer of Code proposal, VFS Quotas, and started running with it. He’s made some progress, as he detailed in a recent post to kernel@ (with code!) , but the nullfs-mount nature of PFSs in Hammer are making it difficult.

Deduplication now eats less RAM

Justin Sherrill — Sun, 14 Aug 2011 01:11:38 +0000

Well, if you tell it to do so. Matthew Dillon has added a user-settable limit to the amount of memory used during deduplication, so if your Hammer-using system is low on RAM, you can conserve. This is probably most useful if you are running DragonFly in an extremely small VM, or if your name is Venkatesh.

(inside joke; Venkatesh has a crazy old desktop for DragonFly.)

Pulse-width modulated time-domain multiplexer!

Justin Sherrill — Wed, 27 Jul 2011 03:15:23 +0000

I really just like that phrase and the action movie feeling of using it, like “Watch out! The pulse-width modulated time-domain multiplexer is targeting us!“ Sorta like a PU-36 space modulator. It’s actually a recently-committed mechanism to improve write performance in Hammer, but my idea sounds more exciting.

Deduplication real world results

Justin Sherrill — Fri, 22 Jul 2011 23:31:04 +0000

I’ve posted about my own results with Hammer deduplication here before, but Siju George put together results from his workplace using actual files in production. He recovered 138G from a 1T disk, and recovered 20% of space from another disk. Not bad for something that’s nearly automatic, and completely free.

Trying out deduplication

Justin Sherrill — Mon, 30 May 2011 23:54:53 +0000

I moved to DragonFly 2.10 over the past few days, and I tried out deduplication, to see what kind of results I would get. The procedure is outlined below. I’m using /home here as an example, just to reduce the amount of text pasted in.

/pfs/@@-1:00004 966000640 566434576 399566064 59% /home

Move my various Hammer pseudo-file systems to version 5, which supports deduplication.

# hammer version-upgrade /home 5

Issue a deduplication simulate command, to see what it guesses will be the savings:

# hammer dedup-simulate /home Dedup-simulate /home: objspace 8000000000000000:0000 7fffffffffffffff:ffff pfs_id 4 Dedup-simulate /home succeeded Simulated dedup ratio = 1.22

That ratio turned out to be pretty accurate for the actual deduplication. I didn’t time it, unfortunately. I don’t know if the time taken is proportional to the amount of deduplication or the total volume of data, though I suspect the latter.

# hammer dedup /home Dedup /home: objspace 8000000000000000:0000 7fffffffffffffff:ffff pfs_id 4 Dedup /home succeeded Dedup ratio = 1.22 462 GB referenced 378 GB allocated 14 MB skipped 6869 CRC collisions 0 SHA collisions 0 bigblock underflows

The end result?

/pfs/@@-1:00004 966000640 505887504 460113136 52% /home

That data space is shared across all file systems, and it’s a 1TB disk, so it’s 7%, or 70GB. I was hoping for more, but I don’t have any obviously duplicated data (no local mail store, no on-disk backups), so perhaps this is normal. 70GB that I didn’t have before is no bad thing, though.

Incidentally, I was able to upgrade my installed software from pkgsrc-2009Q4 to pkgsrc-2011Q1 entirely using pkg_radd -u . Remarkably quick and painless, though pkgin may have been able to do it even faster since it would pull from the same place.

Hot-swap and a bad disk

Justin Sherrill — Thu, 26 May 2011 02:14:50 +0000

If you follow this thread, it has some discussion on how to handle a multi-disk setup and Hammer. If a disk is going bad, you can try mirroring, though you have to be careful how your pseudo-file systems are set up.

More on Hammer design

Justin Sherrill — Fri, 13 May 2011 01:17:21 +0000

I mentioned it before, but Matthew Dillon’s updated his Hammer document, and posted about it. Read on, especially if you like extremely complex plans.

Edit: first link fixed, plus there’s a followup.

Remember to enable deduplication

Justin Sherrill — Thu, 12 May 2011 02:52:25 +0000

I didn’t think of this, but I needed it: if you have an older Hammer system that now can perform deduplication because you upgraded to DragonFly 2.10, make sure to add it to the configuration for that file system, or else it won’t run.

SSDs and how to portion them

Justin Sherrill — Wed, 11 May 2011 01:11:03 +0000

There’s been some discussion on buying a SSD and how to match it with a hard disk, and/or swapcache. Follow the thread for more details.

Hammer and the future

Justin Sherrill — Fri, 06 May 2011 01:59:07 +0000

Matthew Dillon’s been thinking about Hammer, and how to implement clustering well enough to work as a sort of RAID replacement. He’s written up a document describing his plans. Some highlights:

writable history snapshots
quotas and accounting
live rebuilds of data from mirrors
and the same history, mirroring, and snapshots as before.

It’s going to be a while before this “Hammer 2″ becomes a finished product, though, so don’t count on it for the next release.

RAM vs. deduplication

Justin Sherrill — Sat, 23 Apr 2011 00:52:56 +0000

Tomas Bodzar asked about RAM usage with Hammer and deduplication, pointing at this example that shows ZFS requiring… I’m not sure. Lots? Anyway, Matthew Dillon noted that offline deduplication in Hammer would use available RAM/swap for CRCs on all files, but only a limited subset for ‘live’ dedup. For a real-world example, Venkatesh Srinivas described deduplicating about 600G down to 400G, with a machine having only 256M of RAM. Yes, only 256M.

Double buffering in Hammer usually useful

Justin Sherrill — Sun, 03 Apr 2011 01:59:21 +0000

Enabling the vfs.hammer.double_buffer=1 sysctl will greatly improve Hammer performance when you’ve exceeded your memory cache (at a possible slight penalty when you have not) and also speed things up when using live deduplication.

Update: Venkatesh Srinivas says:

“double_buffer makes sense when: 1) you want all CRCs to be checked on reads. 2) you’re running live dedup and care about dedup performance rather than say read-heavy performance; 3) you have swapcache but are often running into the vnode limit in what you can cache.”

So, not always useful.

Hammer speed improvements

Justin Sherrill — Wed, 12 Jan 2011 03:25:49 +0000

Yeah, so those Phoronix benchmarks are crap, but Matthew Dillon went and implemented some things that would speed up Hammer write performance in any case. Read his summary for details.

New Hammer version

Justin Sherrill — Tue, 11 Jan 2011 03:14:45 +0000

The default Hammer version in DragonFly is now version 5, which is the one that includes deduplication. Enjoy, bleeding-edge users! Otherwise, wait for the next release.

Version 6 is there, but don’t upgrade to it yet; there aren’t significant user-visible changes, and the usual disclaimers for new versions apply.

Phoronix benchmarks for Hammer

Justin Sherrill — Sat, 08 Jan 2011 18:25:03 +0000

A Phoronix test of DragonFly’s Hammer filesystem turned up, via Siju George. It’s not really a benchmark as much as it is a speed test, and it’s not a realistic comparison, but it’s interesting to see numbers.

They need a graph that shows how much historical data can be recovered by each file system, or how long fsck takes after a crash.

Update: Matthew Dillon points out the many ways these tests are wrong.