2

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?
0

3 Answers 3

3

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.

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.

0

I did an experiment on my pool, testing various combinations of compression algorithms, encryption and recordsizes.

Compression gives some small benefit (~8% space saving). Whether to use it depends on your resource constraints. The difference between lz4 and zstd is negligible.

zfs list -o name,used,lused pool/monero
NAME          USED  LUSED
pool/monero   167G   182G

I have had no issues while using encryption.

Different recordsizes made practically no difference (~1GB). I tried 256k, 4M, and 16M. The blockchain is immutable, so it's not going become fragmented and less efficient by that on the filesystem as it grows. I went with 16M.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.