1. fdisk -l /dev/sda /dev/sdb | grep "/dev"
   Disk /dev/sda: 320.1 GB, 320072933376 bytes
   /dev/sda1 1 3648 29295616 fd Linux raid autodetect
   /dev/sda2 3648 8511 39062528 fd Linux raid autodetect
   /dev/sda3 8511 38914 244211712 fd Linux raid autodetect
   Disk /dev/sdb: 320.1 GB, 320072933376 bytes
   /dev/sdb1 1 3648 29295616 fd Linux raid autodetect
   /dev/sdb2 3648 8511 39062528 fd Linux raid autodetect
   /dev/sdb3 8511 38914 244211712 fd Linux raid autodetect

1. cat /proc/mdstat
   md2 : active raid0 sda3[0] sdb3[1]
   md1 : active raid1 sda2[0] sdb2[1](F)
   md0 : active raid1 sda1[0] sdb1[1]

(1) 1st parameter "device" actually is optional - should be included in angle brackets <>
Default is "all" devices.

(2) based on (1) a note could be added to documentation: included all block devices like sda, sbd and theirs sda1, sda2, sdb3 ... and multiple devices (MD raid) based on those block devices and logical volumes (LVM) based on those block devices.

Results of test just for case:

1. zabbix_get -s 127.0.0.1 -k "agent.version"
   1.9.9

1. RES=0; for i in sda sda1 sda2 sda3 sdb sdb1 sdb2 sdb3 md0 md1 md2; do let RES+=$(zabbix_get -s 127.0.0.1 -k "vfs.dev.write[$i,operations]"); done; echo $RES
   414839502

1. zabbix_get -s 127.0.0.1 -k "vfs.dev.write[,operations]"
   414839502

Another host with LVM:

1. RES=0; for i in sda sda1 sda2 mapper/pve-root mapper/pve-data; do let RES+=$(zabbix_get -s 10.20.0.31 -k "vfs.dev.write[$i,operations]"); done; echo $RES
   384642
2. zabbix_get -s 10.20.0.31 -k "vfs.dev.write[,operations]"
   384642

the same for sectors, ops, sps.
Actually this behavior could be considered as "bad design" and will be discussed separately (in a ZBX).

<zalex> Has been discussed with Sasha. His point of view that firs parameter still should be optional, i.e. ability to monitor all available devises is enough useful and because should be supported.
So, the note has been added bottom of the table http://www.zabbix.com/documentation/1.8/manual/config/items?&#zabbix_agent
Please review.

(3) 3rd parameter <mode> can be used only if 2nd parameter <type> is "sps, ops, bps". That should be noted in documentation in two tables: "Supported by platform" and "Zabbix Agent".
Should be added that it returns Float and Integer values.
Additionally should be explained briefly that "*ps" means * per second in the "Zabbix Agent" table.

Examples:

1. zabbix_get -s 127.0.0.1 -k "vfs.dev.write[sda,,avg1]"
   196.400000
2. zabbix_get -s 127.0.0.1 -k "vfs.dev.write[sda,sectors]"
   1558962393
3. zabbix_get -s 127.0.0.1 -k "vfs.dev.write[sda,sectors,avg1]"
   ZBX_NOTSUPPORTED
4. zabbix_get -s 127.0.0.1 -k "vfs.dev.write[sda,sps]"
   180.700000
5. zabbix_get -s 127.0.0.1 -k "vfs.dev.write[sda,sps,avg1]"
   181.333333

1. zabbix_get -s 127.0.0.1 -k "vfs.dev.write[,,avg1]"
   794.066667
2. zabbix_get -s 127.0.0.1 -k "vfs.dev.write[,sectors]"
   8104448149
3. zabbix_get -s 127.0.0.1 -k "vfs.dev.write[,sectors,avg1]"
   ZBX_NOTSUPPORTED
4. zabbix_get -s 127.0.0.1 -k "vfs.dev.write[,sps]"
   837.600000
5. zabbix_get -s 127.0.0.1 -k "vfs.dev.write[,sps,avg1]"
   855.200000

<zalex> Tested just for case. Parameters sps and ops really are "values per second".

(4) default value for "vfs.dev.read|write" actually is different for different OS but not "sectors" as noted in a table "Supported by Platform".
How this error happened: my error !
It appeared in a revision when I've changed table's "columns style" http://www.zabbix.com/documentation/1.8/manual/config/items?rev=1293663369
I remember this **single** case when I doubted but at the end I've added a word (default) to "sectors". Sorry on that, should be removed.

But I'm going to add a note to first column, so it will be: "type (defaults are different under various OSes)".
I consider this as very important, especially because the tables located at the different pages in 2.0 doc.

(1), (3), (4) RESOLVED in http://www.zabbix.com/documentation/1.8/manual/config/items
(2) resolved too.
RESOLVED, 2.0 documentation will be updated after approval of these changes.

<zalex> Approved by Martins (IRC), 2.0 doc has been updated.
CLOSED.

Issue CLOSED