Christopher Berner
Christopher Berner
Hmm, I haven't played with direct i/o a whole lot, but here are a few hypotheses: 1) write back buffering and coalescing. Without direct i/o all the `write()`s which are...
> So this sounds like something that could be optimized? It's less trivial than it seems. Because pages can be allocated at different orders, the size of the cached page...
> So this sounds like something that could be optimized? For a free'd page, its contents should not matter, should it? So it could just be declared clean and but...
I'm not sure. Have you tried profiling with and without direct_io? The `just flamegraph` target will output a flamegraph of the lmdb_benchmark run
I tried your diff, but it panics with alignment errors in `FileBackend`. If you send a draft PR that properly handles all the alignment, I'll look into this further
> Depending on the file system you use, the only thing required is to increase DB_HEADER_SIZE where for me 512 bytes was sufficient for ext4. Unfortunately, I hit a panic...
I'm on the 6.8 kernel, but it was this assert in your diff: `assert!(buffer.as_ptr() as usize % self.mem_align == 0);`
It required alignment of 512 Sent from my phone On Mon, Jul 22, 2024, 10:26 PM Adam Reichold ***@***.***> wrote: > I think the assert is correct and necessary, i.e....
Yep, thanks for contributing that optimization!
Uh oh! I'll take a look. It's been a while since I ran ord, will these steps reproduce the issue? ``` bitcoind -txindex cargo run --release -- --data-dir=./ord_db --db-cache-size 2147483648...