Background
I got my hands on a few unwanted HP Gen9 servers with lots of reasonably sized SAS drives. Don't laugh, but it was like in a sci-fi movie where the army would try to kill all the aliens as default action. The people who owned the hardware were literally scared of touching the hardware.
The consensus in the company was to hammer the drives and destroy the hardware because it will make too much noise, too much heat and get broken. Perhaps it could be standard response from people who does not understand the hardware well enough.
Perhaps a good example of one man's trash is another man's treasure :)
Test System
The test system consists of a Proxmox VE installation over a machine with Intel E5-2620 v4 and 32GB DDR4 memory. This means the default ARC size is about 16GB. The decision to use such a low memory configuration was to reduce the effect of the ARC cache.
The installation was made on an 8x 1.8TB 12G SAS HDD (EG1800JEMDB) with RAID-Z3 and ashift value of 12. The drives were connected to a SAS expander which was connected to P440ar with firmware version 7.00-0 and running in HBA mode.
Tests were executed inside a VM with 4 CPU cores and 4GB RAM. Several volumes of 100GB size, and volblocksize ranging from 8k to 1024k was mounted within the VM into different folders and fio command was used for tests.
Tests Performed
The basic read, random read (randread), write and random write (randwrite)) tests were performed. The write tests were performed with and without fsync. The file size used was 80GB and created ready prior to running the tests. The tests were performed with
fio bs sizes of 4, 16 and 64For the second part of the read tests with cache. The ARC size was reduced to 1GB. It was the minimum value which seemed to work according to this bug report.The size was manipulated by overriding it using a modprobe.d file
options zfs zfs_arc_max=1048067201
The read tests were repeated again with 1GB ARC value so the results would be comparable with the cache tests. In addition, the read tests were modified to read 10GB with 8 times loop of same test to be able to train the cache first.
Test Data
The in-compressible test data was created using the following fio command:
fio --name=test --create_only=1 --filesize=80G --directory=VOLUME_MOUNTPOINT
The compressible test data was created using the following fio command:
fio --name=test --buffer_pattern=0xdeadbeef --buffer_compress_percentage=75 --create_only=1 --filesize=80G --directory=VOLUME_MOUNTPOINT
The compressible data was found to be compressible to roughly 1/4 size of the original.
| volblocksize | ratio | used | lused | compress | actual savings |
| 8K | 1.99x | 92.4G | 80.9G | zstd | -1.14x |
| 16K | 2.00x | 92.0G | 80.7G | zstd | -1.14x |
| 32K | 2.67x | 46.0G | 80.6G | zstd | 1.75x |
| 64K | 3.20x | 23.0G | 80.6G | zstd | 3.5x |
| 128K | 3.57x | 22.9G | 80.5G | zstd | 3.5x |
| 256K | 3.78x | 22.9G | 80.5G | zstd | 3.5x |
| 512K | 3.90x | 20.0G | 80.6G | zstd | 4.03x |
| 1024K | 3.90x | 19.3G | 80.6G | zstd | 4.17x |
In some cases actual savings is more than the compression ratio reported. Perhaps this could be due to zeros accepted as null blocks instead of being in the compression statistics.
No comments:
Post a Comment