xmrk ₿ ⚡️ on Nostr: I put .bitcoin/chainstate directory on ZFS, and quite satisfied with the result. ...
I put .bitcoin/chainstate directory on ZFS, and quite satisfied with the result.
Before, processing a block could take 4 minutes, lightning complained about failed healtcheck 10 times a day. After 23 hours with ZFS, I observe just 1 healtcheck failure, and block processing is < 30s.
I also set /sys/module/zfs/parameters/zfs_arc_min and zfs_arc_max to 5.5 GB and 7 GB respectively. This is a laptop with 8 GB RAM and 2 HDDs, running just bitcoind, lnd is on another laptop. Just moving the chainstate to the other HDD did not help that much.
In theory, this should keep most of chainstate in cache, even when peers do a lot of historical queries. (The rest of .bitcoin is NOT on ZFS, but on Btrfs.)
Not the most elegant solution - ZFS help mostly because it has separate cache. But even if everything was on ZFS, I think ZFS's caching algo would notice that chainstate is read much more frequently than the rest, and keep most of it in cache - but I haven't tested this.
Before, processing a block could take 4 minutes, lightning complained about failed healtcheck 10 times a day. After 23 hours with ZFS, I observe just 1 healtcheck failure, and block processing is < 30s.
I also set /sys/module/zfs/parameters/zfs_arc_min and zfs_arc_max to 5.5 GB and 7 GB respectively. This is a laptop with 8 GB RAM and 2 HDDs, running just bitcoind, lnd is on another laptop. Just moving the chainstate to the other HDD did not help that much.
In theory, this should keep most of chainstate in cache, even when peers do a lot of historical queries. (The rest of .bitcoin is NOT on ZFS, but on Btrfs.)
Not the most elegant solution - ZFS help mostly because it has separate cache. But even if everything was on ZFS, I think ZFS's caching algo would notice that chainstate is read much more frequently than the rest, and keep most of it in cache - but I haven't tested this.