It's curious to see how times have changed. Soft-updates are indeed a very clever solution to the problem of file system consistency in the face of possible failures like OS crashes or power outages.
While journaling "simply" writes a journal of FS ops to a continuous area of the drive (especially important for mechanical drives) which is fsynced faster than random writes across platters, Soft-updates opts to be really clever with the way FS ops ordered, so that what's actually on the drive is always consistent, even with decent amount of write caching. It doesn't guard file content, though, just the file system itself.
Soft-updates is what enabled the BSD's to support short-lived files never touching the physical drive. You could create a file, write to it, read it, close and delete it, and if this was done in a reasonably short amount of time, no writes whatsoever got to the actual hardware. It was wonderful with software which used to generate a lot of temp files, like building C software.
OTOH, if a write got trough to the hard drive, Soft-updates guaranteed that file system structures get written in a way so that if an OS crash or a power failure happened at any single time, the only downside could be some unreferenced blocks, which could be garbage collected later; assuming hardware doesn't lie about fsync, of course...
I think ext4 supports this kind of short-lived-files-never-touch-the-drive caching.
There is a port of Hammer2 being worked on for OpenBSD/NetBSD/FreeBSD/Linux.
I can only hope the developer delivers this to OpenBSD and someone then maintains it since the developer, based on the readme, doesn’t appear to want to maintain OpenBSD or NetBSS longterm.
This website is a breath of fresh air, and an inspiration to keep my sites simple and accessible. I appreciate that the one image (aside from the icons) has the caption beneath:
"A giant puffer fish fixing old machines. A girl kneels nearby. The narrator says «There, I found it»."
I love how she trades the huge Bash manual for the brain interface, or distracts the sniper with "bad UI design". The world is grim and surreal, perfect setting for the story. There's a statement somewhere in there.
While journaling "simply" writes a journal of FS ops to a continuous area of the drive (especially important for mechanical drives) which is fsynced faster than random writes across platters, Soft-updates opts to be really clever with the way FS ops ordered, so that what's actually on the drive is always consistent, even with decent amount of write caching. It doesn't guard file content, though, just the file system itself.
Soft-updates is what enabled the BSD's to support short-lived files never touching the physical drive. You could create a file, write to it, read it, close and delete it, and if this was done in a reasonably short amount of time, no writes whatsoever got to the actual hardware. It was wonderful with software which used to generate a lot of temp files, like building C software.
OTOH, if a write got trough to the hard drive, Soft-updates guaranteed that file system structures get written in a way so that if an OS crash or a power failure happened at any single time, the only downside could be some unreferenced blocks, which could be garbage collected later; assuming hardware doesn't lie about fsync, of course...
I think ext4 supports this kind of short-lived-files-never-touch-the-drive caching.