> > * Improved performance > there are known scenarios where it does degrades performance.
I meant in the general case. > > * Faster recovery latency after a crash > this is just not true at all. Effectively, background fsck isn't implemented yet under OpenBSD and NetBSD (FreeBSD has this feature available since 5.x), but I think it will be soon in OpenBSD: ---- http://kerneltrap.org/node/6 JA: If you still have to run fsck, even with soft updates, why wouldn't a journaling filesystem be welcome? Theo de Raadt: Because, as the paper shows, a journaling filesystem is typically slower, and only really performs well on multiple platters or using an nvram journal. That said, there are changes coming which will make soft update filesystems be capable of background fsck. As it is now, you can mount a soft update filesystem after a crash, and it will work, but the block allocation bitmaps may state that certain blocks are in use, when they are not. So work has to happen to permit background block cleanup. ---- In my message I refered to the general ideas behind softupdates more than to any actual implementation.
