If a customer sees the following errors messages on their ESX Servers whilst connected to a NetApp NFS Cluster:
vmkernel: 110:01:18:42.510 cpu1:1031)WARNING: BC: 1536: Unexpected short write; expected file length 1430733, requested 122368 bytes at 1310720, got 65536
WARNING: BC: 2644: Unexpected short write; initial file length 181928, expected length 186368, short by 22528 bytes
The issue is with the NetApp Cluster as defined in the resolution below.
During initial mount request the NetApp NFS client and the ESX server negotiate the max transfer size - the largest number of bytes per write/read request. If the maximum transfer size is reduced (for example, failover to another box in a cluster ) and the NFS client request read/write using the old value the filer will return short read/write operation. This can happen in the case of one of the NFS boxes in the Cluster failing and the NFS failing over to a different box with a different Max Transfer Size.
In this case, the filer returns less than what the client requested. The difference in sizes may be filled with zeroes by the NFS client to make up the difference.
For example, the negotiated max transfer size is 128k , the failover happens, the second NetApp filer takes over, but it hasnfs.tcp.xfersize set to 64k.
When the client requests write of 128k filer returns only 64k. The remaining 64k is filled with zeros and this is very dangerous situation which can cause corruption on the file system.
You must ensure that on all nodes in the NetApp cluster the nfs.tcp.xfersize is set to the same value to avoid any such issues.
Based on VMware KB 1006854