Kai Krakow
Kai Krakow
Well, I purged my hash table on this machine. Let's look again when the first full scan is done. I can still do this on a second machine but that's...
> I was thinking more along the lines of just adding > > ``` > BEESLOG("flushing extent #"
I think you're correct, I should move it down. I'll bump log verbosity up once I run into the problem again.
On the other machine, I reverted the hash table size back to the original size (without purging it), and the behavior stopped: It no longer constantly writes 1.14 MB/s. So...
> just before the `catch_all`. That will log which extent numbers are being flushed. The log will then contain a timeline of extent scan activity and dirty hash flushes, and...
The machine where I reduced the hash table size also returned to this behavior over night... It fluctuates between 1.12 and 1.14 MB/s now. So it probably has nothing to...
Watching the bees process in `htop` shows that it is just writing, `IO_WBYTES` increases at a constant rate while `IO_RBYTES` only changes a little every once in a while.
So, is this a feedback loop? I don't think that rate limiting the writeback even further isn't constructive. Would anything change if I placed `$BEESHOME` on another partition? Does bees...
Seems to be fixed with current master.
I'd appreciate this... BTW: Meson is what configures the build system, ninja actually runs the build system. You don't need much documentation for ninja, you just use it through running...