Duplex mismatches only result in lost packets when both sides of the wire try to talk at the same time. If the applications in question are single-packet request/response - eg ping - then one will not see the "problem" with a duplex mismatch.
It is possible that link-level errors were only detected at the switch, in which case netstat would not show much. It may also be the case that the link-level errrors detected by the driver were not propagated up to netstat? Ethtool might be a good thing to use in addition to netstat.
If there were packet losses, one would expect to see retransmissions recorded by the upper layer protocol(s) - TCP, or NFS in this case.
Some boilerplate on duplex:
How Autoneg is supposed to work:
When both sides of the link are set to autoneg, they will "negotiate"
the duplex setting and select full duplex if both sides can do
full-duplex.
If one side is hardcoded and not using autoneg, the autoneg process
will "fail" and the side trying to autoneg is required by spec to use
half-duplex mode.
If one side is using half-duplex, and the other is using full-duplex,
sorrow and woe is the usual result.
So, the following table shows what will happen given various settings
on each side:
Auto Half Full
Auto Happiness Lucky Sorrow
Half Lucky Happiness Sorrow
Full Sorrow Sorrow Happiness
Happiness means that there is a good shot of everything going well.
Lucky means that things will likely go well, but not because you did
anything correctly :) Sorrow means that there _will_ be a duplex
mis-match.
When there is a duplex mismatch, on the side running half-duplex you
will see various errors and probably a number of late collisions. On
the side running full-duplex you will see things like FCS errors.
Note that those errors are not necessarily conclusive, they are simply
indicators.
there is no rest for the wicked yet the virtuous have no pillows
