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.