What settings for ZFS dataset containing blockchain directory?

Question

The ZFS file system allows the user to specify various characteristics when creating datasets, or even after their creation. For example:

zfs create -o compress=lz4 -o atime=off zroot/data/monero

or

zfs set recordsize=1024k zroot/data/monero

When creating a ZFS dataset for containing the blockchain's data-dir, what are some appropriate settings for that dataset?

• Presumably atime=off is a good one. The blockchain is constantly written to, so there's no need to spend resources on tracking access times, I would think.

• I would think compression may not be a good idea. If the blockchain is filled with keys, that's a lot of entropy that can't be compressed really anyway, so maybe it's not worthwhile to spend resources on it. Then again, (a) maybe there is some required boilerplate filler taking up space, and (b) from the FreeBSD handbook:

If LZ4 does not achieve at least 12.5% compression in the first part of the data, the block is written uncompressed to avoid wasting CPU cycles trying to compress data that is either already compressed or uncompressible.

• It's common to consider recordsize as a potentially critical choice affecting database performance because databases tend to get updated frequently (e.g., taking a case where recordsize=512k and database records are 16k, it would be wasteful to read 512k to change a 16k database record and then have to rewrite the whole 512k back). I imagine lmdb's use in Monero might lend itself to an ideal recordsize. If so, what might that be?
• In the case of a blockchain, where data is generally only appended, maybe recordsize isn't actually important. But what might an optimal recordsize be if one wanted to optimize for chain reorgs?

Answer 1

The recordsize must be the same as the system's VM page size, which is usually 4KB on most systems. For blockchain data, compression is a waste of CPU. Cryptographic data is inherently incompressible.

Answer 2

Compression gets you a little bit with the Monero blockchain:

# zfs list -o name,used,lused tank/xmr
NAME         USED  LUSED
tank/xmr   155G   166G

The actual txns aren't compressible but the database structure has some slack. If you have more CPU than I/O bandwidth then there's a mild benefit. You can benchmark your system to check with time and zpool iostat tank 1 while copying a piece of the blockchain.