A wish came true: NetBSD finally has a journaling file system. Simon Burge added support for WAPBL, Write Ahead Physical Block Logging file system journaling, to NetBSD-current’s main branch today.
The main purpose of a journaling file system is to avoid a time consuming file system checks after a power failure, system crash or similar problem. But it can also help to improve performance considerably depending on the design. As I was curious about WAPBL’s performance impact I ran my usual benchmark (extracting the NetBSD 4.0 source tar archives). And the result is very encouraging: FFS required 15:19 minutes to finish the benchmark without logging and only 3:24 minutes to finish it with logging. It seems that WAPBL provides similar speed improvements as soft dependencies and keeps your file system safe at the same time.
A big thank you to Wasabi Systems for donating the code and to Simon Burge and all the other developers for integrating WAPBL into NetBSD!
I also think its great the WAPBL stuff got added. well done!
For your test, was each run across a distinct reboot? if not, I wonder if the amount of bufcache from one or other run altered the runtime behaviour of the system as a whole?
Also, what were the times to rm -rf or newfs the filesystem(s) each time?
(maybe the short answer is not relevant!)
cheers
-G
The buffer cache works at a file system level, not at a block device level. Unmounting a file system will therefore invalidate all the cached content of that file system. And even if that wasn’t the case it shouldn’t influence the benchmark which consist of write operations.
The “newfs” command doesn’t (have to) know about journaling. The option is only activated at mount time.
I didn’t test “rm -rf”.
Some questions for clarity:
“FFS required 15:19” – is this with or without soft-updates?
How large is the source archive? (did you preload it before extracting it the first time?) Does the extracted content fit into RAM? What happens if you de-archive an archive larger than RAM?
There are so many interesting things to measure here 🙂 I’d suggest a 4-way comparison between async, noasync, softupdates and WAPBL. Also, a run of randomio (http://arctic.org/~dean/randomio/) on each method would be nice.
No, I didn’t use soft dependencies because they cause stability problems (e.g. locking up your system) and have a high disk of data loss. I’m not using them on my server for years because of these problems.
The extracted content fits into the memory of the system but the benchmark scripts runs “sync” as the last step to flush all disk buffers. The content was on a memory file system as mentioned in the article which should make pre-loading irrelevant.
I’m sorry but I’m not interested in either asynchronous mode or soft dependences. I’ve focused on benchmarking modes of operation that I’m willing to use on my server.
Soft-updates have been established for years as 100% stable and production ready with no risk of data-loss (in FreeBSD) because it prevents data-loss by ordering writes. You just do not implement it on your root slice due to space issues.
I think your benchmark and your results are lacking and inconclusive because without comparative results to other methodologies that also speed plain-old sync writes.
I’m aware of the benefits that soft dependences promises. They have however not proven to be stable under NetBSD. If you look at the archive of the tech-kern mailing list you will find a statement by Andrew Doran about the various problems with this technology. The situation might be different for FreeBSD because Kirk McKusick maintains the code himself as far as I know.
My results are conclusive for my personal use because I don’t use soft dependences on my servers after various problems in the past.
Please remember that this is a personal Blog and not a scientific technology review. If your requirement for benchmark results are different please run your benchmark and publish the result.