We have ran all of the tests on a Debian Squeeze install (current stable) but unfortunately there was a difference and that is the kernel version. All of the single disk/ssd, software raid and Flashcache tests were made on 2.6.32 while the Bcache test was ran on kernel 3.1.0 (whole kernel source was checked out from Bcache repository and the config from the Debian 2.6.32 kernel was applied). The difference with Bcache is because they recommend to run with the latest kernel from their repository and also the fact that we couldn't find the 2.6.32 kernel patch for Bcache. On the other hand Flashcache is officially tested and supported on kernel versions 2.6.18, 2.6.20 and 2.6.27-32 so we didn't want to try it against 3.1.0

Software raid was used for the S-ATA disks and write caching was enabled for those. The filesystem used was XFS, the elvator CFQ. The settings for both flashcache and bcache are below; for flashcache we tested with skip_seq_thresh_kb=512 and with raid0 we also did a test with skip_seq_thresh_kb=4096 .

--------------------- Flashcache ---------------------

dev.flashcache.sde+md0.fallow_delay = 900 dev.flashcache.sde+md0.fallow_clean_speed = 2 dev.flashcache.sde+md0.cache_all = 1 dev.flashcache.sde+md0.fast_remove = 0 dev.flashcache.sde+md0.zero_stats = 0 dev.flashcache.sde+md0.reclaim_policy = 0 dev.flashcache.sde+md0.pid_expiry_secs = 60 dev.flashcache.sde+md0.max_pids = 100 dev.flashcache.sde+md0.do_pid_expiry = 0 dev.flashcache.sde+md0.max_clean_ios_set = 2 dev.flashcache.sde+md0.max_clean_ios_total = 4 dev.flashcache.sde+md0.dirty_thresh_pct = 20 dev.flashcache.sde+md0.stop_sync = 0 dev.flashcache.sde+md0.do_sync = 0 dev.flashcache.sde+md0.io_latency_hist = 0 dev.flashcache.sde+md0.skip_seq_thresh_kb = 512

--------------------- Bcache ---------------------

#make-bcache -B /dev/md0 #make-bcache -C -w4k -b1M --writeback /dev/sde #echo /dev/md0 > /sys/fs/bcache/register #echo /dev/sde > /sys/fs/bcache/register #mkfs.xfs /dev/bcache0 #ls /sys/fs/bcache/ 34abebd9-eb8a-4556-8d6c-6166d2850379  register  register_quiet #echo 34abebd9-eb8a-4556-8d6c-6166d2850379 > /sys/block/md0/bcache/attach [ 2566.626819] bcache: Caching md0, inserted new UUID 795e3647-bc1e-4be5-874a-d0cb4bbb7496 # echo 1 > /sys/block/md0/bcache/writeback

The test results should be carefully analysed and the context needs to be taken into account , meaning for example that the S-ATA version used is 2 so in theory the limit per device is 3Gbit/s and if you take into account that the IOzone 8GB read performance test reports for one S-ATA rotational disk 2311GB/s then it's clear that the Linux kernel's disk cache was hit during this test as the memory was enough to cache it (16GB ram).

On each host which needs monitoring you need to copy the scripts : zarafa-zabbix-stats-sender and zarafa_configured_cache_size.sh and set them up in cron. Edit both scripts and put/adjust the hostname and zabbix server entries according to each of your monitored hosts.

Both scripts above rely on zabbix_sender in order to send the data to the Zabbix server. The cron entries are: #send zarafa cache statistics to zabbix * * * * * /usr/bin/python /usr/local/bin/zarafa-zabbix-stats-sender > /dev/null 2>&1 1 0,6,12,18 * * * /usr/local/bin/zarafa_configured_cache_size.sh > /dev/null 2>&1 Import the XML file in Zabbix using the web interface and associate the host(s) with Template_app_zarafa_stats_active. Create screens as needed. We recommend to use this together with Paulson McIntyre's Apache monitoring script and the Mysql extended monitoring provided by appaloosa-zabbix-templates as they will give you a good view in your ZCP installation.