Skip to main content
Effective December 3 - NetApp adopts Microsoft’s Business-to-Customer (B2C) identity management to simplify and provide secure access to NetApp resources. For accounts that did not pre-register (prior to Dec 3) access to your NetApp data may take up to 1 hour as your legacy NSS ID is synchronized to the new B2C identity. To learn more, Read the FAQ and Watch the video.
NetApp Knowledge Base

Why is the client side I/O traffic high while the disk read is low in Data ONTAP 7-mode?

Last Updated:

Applies to

  • Data ONTAP 7-Mode


High network traffic is seen on the Ethernet or FCP, but from sysstat output, the disk read throughput is very low.


  •  Data retained in the cache.

The data that clients want to read is small enough to be retained in the filer's RAM. For example, a file in a volume is 300 MB in size. If the client reads it sequentially and reads it often, and there is no other client or IO request, this file will be retained in controller system memory. At this time, no disk read will be needed, so high network traffic (both Ethernet or Fibre Channel (FC)) is seen, but with a very low disk read.

  • The target file is a sparse file with many holes.

The file contains holes that do not occupy any disk space, but if the client reads the entire file, Write Anywhere File Layout (WAFL) will transfer a stream of 0x00 to the client. Logical Unit Number (LUN) also have holes. If a new LUN is created, it is essentially made up of holes. As long as it is filled with data on the client, the holes will be filled with real data. So if an IO request is issued on a client to read the newly created LUN, for example, raw device traffic on the network will be seen as very high but the disk read is almost zero. This can also be checked in the readahead object. In the readahead.hole output of stats, it appears to be very high

The following example shows 224 (122546-122322) requests that are not targeted to a hole:






Additional Information

At times, IO test tools may return false results when targeting a newly created LUN because read IO from the LUN does not require any disk IO. Therefore, the result is just the maximum value of the external network's (FC, Ethernet) bandwidth, which probably cannot stand for the real environment.