ZFS Best Practices¶
This section summarizes best practices when creating ZFS storage pools.
What to do¶
- Dedicate some part of installed memory to ARC. ARC will intelligently cache data in memory, and speed read operations.
- Use ECC memory. ZFS uses memory intensively and stores data in memory. It cannot cope with random bit flips or broken memory slots.
- Use compression. Compression may help increase performance dramatically and save some space. Danube Cloud has lz4 compression turned on by default.
- Storage pool should be created using whole disks as this will allow ZFS to automatically partition the disk to ensure correct alignment.
- If possible, use a dedicated device for hosting the ZFS intent log. This will boost the performance of synchronous writes, and virtual machines in Danube Cloud will benefit.
- When not sure which RAID type to use, go for stripped mirror, which makes a good trade-off between speed and redundancy. If more capacity is needed, RAIDZ2 provides an excellent trade-off between capacity and redundancy.
- When using RAIDZ, choose stripe width based on your IOPS needs and the amount of space you are willing to use for parity information.
- For best performance on random IOPS, use a small number of disks in each RAID-Z group. E.g, 3-wide RAIDZ1, 6-wide RAIDZ2, or 9-wide RAIDZ3. For even better performance, consider using mirroring.
What not to do¶
- Do not mix various RAID vdevs in a storage pool, e.g. do not use mirror combined with RAIDZ. This might lead to poor performance and redundancy levels.
- Do not mix disks of various speed in a RAID vdev. The speed of the slowest disk will be a bottleneck, and it may degrade the performance of the whole storage pool.
- Do not mix disks of various size in a RAID vdev as this might lead to space loss.
- Do not partition a device used for hosting ZFS intent log, use the whole device every time.