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.
Could the discards be entered into the log?
On Wed, Oct 19, 2016 at 09:50:57AM +0200, Jarom??r Dole??ek wrote:
> Can you confirm whether you had the filesystem mounted with 'discard'
> option by chance?
>
> FYI, discard hides block deallocation changes from wapbl log until
> discard is finished for the blocks, so pretty much throws consistency
> out of window. I plan to actually change FFS to disable discard when
> logging is enabled as stopgap measure, because of this. Later, discard
> needs to be changed, so that it doesn't interfere with block free
> maps.
>
> Jaromir
>
> 2016-10-18 19:10 GMT+02:00 bch <brad.harder%gmail.com@localhost>:
> > Yesterday I had an unclean shutdown while ./build.sh distribution (battery
> > on laptop died). On reboot i had corrupted files similar to other week after
> > wapbl refactor. Could wapbl stand to have more demanding testing thrown at
> > it? Can we simulate unclean shutdown with vn file-based filesystem and run
> > aggressive tests on it?
--
Thor Lancelot Simon tls%panix.com@localhost
"The dirtiest word in art is the C-word. I can't even say 'craft'
without feeling dirty." -Chuck Close