22nd February 2010
Join Date: May 2008
Location: Budel - the Netherlands
Thanked 182 Times in 149 Posts
Update on tmpfs and swapcache work (in master)
Matthew Dillon in a post to the DragonFlyBSD users mailing list
Subject: Update on tmpfs and swapcache work (in master)
From: Matthew Dillon
Date: 20 Feb 2010
I've nailed a few more bugs in tmpfs, including one that caused
excessive paging to swap, a VM object leaking in kernel virtual memory
(try to imagine that visually <grin>), and stomped a few bug reports
related to fsstress tests Venkatesh ran.
tmpfs is now working very nicely with memory & swap, with minimal
paging to swap when memory is available to hold the data. It is
starting to look like it will be a very good fit against SSD-based
swap and swapcache, and frankly tmpfs should work well with HD-based
swapcache is also faring very well in all tests done so far, for
those people interested inconfiguring Solid State Drive (SSD) based
swap space. The manual page has been updated and the data caching
capability has gotten a little more sophisticated with the new
Some tuning with disklabel64 (for labeling the SSDs) has been done to
align the partition base and reduce write amplification and write
combining effects by the SSD drive firmware. Swapcache also does a
pretty good job clustering and linearizing write operations.
I am running ongoing tests on pkgbox64 with one of these Intel X25-V
40G SSDs with 32G of swapcache configured and so far I haven't even
managed to tick over the wear meter. It started at 99% and it's
still 99% after 569GB worth of intentionally heavy write activity.
The X25-V has a stated write durability of around 40TB but with
static wear leveling MLC cells theoretically have a 10,000 erase
cycle endurance which would be more around 400TB. The Intel SSD
apparently does a combination of static and dynamic wear leveling.
A key point here is the swapcache is laying down data very efficiently
compared to what a filesystem-on-SSD would do, and this should result
in significantly less write amplification than we would otherwise expect.
My expectation is we could get upwards of 150-250TB of write durability
out of this particular device. I won't know for probably another week
or two at the rate pkgbox64 is currently writing but if it turns out to
be true then MLC-based SSDs will be totally viable at higher write
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump