Kai Krakow
Kai Krakow
> OK, I've recreated beeshome (now with a larger hash table file). So if I just leave it running, it should eventually make sure that no partially unused extents exist...
Okay, I queued up an initial idea in https://github.com/kakra/bees/tree/integration. Please don't pull from that branch, it will be force-pushed on many occassions. But feel free to cherry-pick. I'm rebasing it...
Hmm, it's not yet quite done... During normal startup, log settings are still applied too late. But feel free to merge anyways.
Is this a coredump? It says "Aborted" without "core dumped". I've posted a few PR that may have an impact on this. You may want to try merging those locally...
Could you rebuild glibc, then rebuild bees?
I don't know, a similar (or identical) crash crept in before: https://github.com/Zygo/bees/issues/124 Seems to be Gentoo specific. Rebuilding glibc under new gcc seems to fix it, as you tested. I...
> > Seems to be Gentoo specific. > > FWIW I've never seen this behavior on Debian. @Zygo Yes, because in Debian, glibc, gcc and all other packages are from...
Here's another one which fits this category even better: ``` Nov 18 14:29:53 jupiter beesd[24536]: crawl_281[2557]: Opening src bfr 4K [0x46ce89000..0x46ce8a000] fid = 281:320 fd = 8 'home/kakra/.VirtualBox/VDI/Ubuntu.vdi' Nov 18...
PS: I needed to start over and restore from backup, so I'm seeing a lot of those now. Underlying problem is: Do NOT ever (repeat: do NOT) use bcache with...
Is there something like a debug level?