Re: Wapbl correct and stable again?

[Jaromír Doleček <jaromir.dolecek%gmail.com@localhost>]

2016-10-21 1:56 GMT+02:00 bch <brad.harder%gmail.com@localhost>:
> I just had a kernel fault (might be audio subsystem, will investigate), but
> with this latest (7.99.40) kernel I'm still getting corruption. I don't know
> if it's new code in the filesystem, or bad luck that I'm faulting so much,
> exposing something that's already been there for a while, but this seems
> pretty unstable.

There weren't really any significant changes to wapbl or ffs so far.
Just some slight refactoring, to prepare code for first real fixes.

Within kernel, there is some active development with wm(4) and network
subsystem, maybe that could be related to your problem. Those however
shouldn't really matter for your local build.sh builds.

If you want, you can try reverting all the latest wapbl changes in
your local checkout, and see if it improves situation for you:
sys/kern/vfs_wapbl.c to rev 1.78
sys/sys/wapbl.h to rev. 1.17
sys/ufs/ffs_wapbl.c to rev 1.32
sys/ufs/ffs_extern.h to rev 1.82
sys/ufs/ffs_alloc.c to rev. 1.151

> On Oct 20, 2016 4:10 PM, "Thor Lancelot Simon" <tls%panix.com@localhost> wrote:
>>
>> Could the discards be entered into the log?

That should eventually happen, yes. That said, WAPBL needs any love it
can get, and trying to also fix it WRT discards wouldn't be really
helpful at this moment, in my opinion. That's why I plan to just go
with disabling discard when log is on, for now.

Discards really still need quite some attention. They need the fix WRT
reboots, performance fix to not be so horribly slow, then fix to not
hide the freed blocks in discard queue in order to not screw up block
allocation and hence cause fragmentation (it matters even for SSDs).
Then we can worry about making it really working with log :) It would
be awesome if someone would take care of it.

Jaromir