2016-10-21 1:56 GMT+02:00 bch <[email protected]>: > 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" <[email protected]> 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
