Hi there, I am currently testing with an Intel 520 series 240GB. According to its datasheet the performance for sequential writes is: (http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-520-specification.pdf) -Compressible Performance Sequential Write Sata 6Gb/s: 520 MB/s -Incompressible Performance Sequential Write (up to): 235 MB/s Per default it seems that the Sandforce Controller can compress some data: /usr/local/bin/fio --rw=write --name=intel520-run0 --bs=128k --direct=1 --filename=/dev/sdb --numjobs=1 --ioengine=libaio --iodepth=32 intel520-run0: (g=0): rw=write, bs=128K-128K/128K-128K, ioengine=libaio, iodepth=32 Jobs: 1 (f=1): [W] [100.0% done] [0K/475.7M /s] [0 /3629 iops] [eta 00m:00s] write: io=228937MB, bw=394254KB/s, iops=3080 , runt=594619msec The performance with "--zero_buffers" is nearly the same: /usr/local/bin/fio --rw=write --name=intel520-run0 --bs=128k --direct=1 --filename=/dev/sdb --numjobs=1 --ioengine=libaio --iodepth=32 --zero_buffers intel520-run0: (g=0): rw=write, bs=128K-128K/128K-128K, ioengine=libaio, iodepth=32 Jobs: 1 (f=1): [W] [100.0% done] [0K/490.4M /s] [0 /3741 iops] [eta 00m:00s] intel520-run0: (groupid=0, jobs=1): err= 0: pid=13274 write: io=228937MB, bw=401393KB/s, iops=3135 , runt=584044msec With the option "--refill-buffers" it comes down to incompressible performance: /usr/local/bin/fio --rw=write --name=intel520-run0 --bs=128k --direct=1 --filename=/dev/sdb --numjobs=1 --ioengine=libaio --iodepth=32 --refill_buffers Jobs: 1 (f=1): [W] [100.0% done] [0K/242.8M /s] [0 /1852 iops] [eta 00m:00s] intel520-run0: (groupid=0, jobs=1): err= 0: pid=13289 write: io=228937MB, bw=203629KB/s, iops=1590 , runt=1151267msec I would suggest a slight hint in the HOWTO at the "refill_buffers" option. Maybe like: "This option is useful to circumvent compression techniques of device controllers in order to get the performance using incompressible data." -Georg -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
