This is what the Ixora web tip on multiblock reads says on the matter ...
"Unfortunately, if you use buffered I/O the operating system will service multiblock reads as a series of small I/O operations anyway and the only benefit from multiblock reads will be a small saving in CPU usage. In this case the multiblock read count should be approximately equal to the typical track length to take advantage of track buffering and no larger lest the optimizer be deceived."The key word there is "buffered". If your filesystem is able to do direct I/O, and is configured to do so, then the large multiblock read principle applies. But, if your filesystem I/O is buffered, then there is very little to gain.
You can tell whether your filesystem is servicing multiblock reads atomically using the sar -d statistics. Divide the blocks per second metric by the reads+writes per second metric to get the average I/O size expressed in 512 byte blocks. If that is consistently close to 16 blocks (8K) while doing "large" multiblock reads then the buffering is indeed breaking your reads up into 8K chunks and you'll need to switch to raw or direct I/O to get the real benefit of multiblock reads. Note that the 8K is not invariant. Many Unix operating systems can also work with 4K file system blocks, and some use 16K.
If the UNIX filesystem can only do an 8K I/O at most, and my Oracle blocks are 8K, then setting db_file_multiblock_read_count to a value higher than 1 won't provide any performance benefit. True?