Comment 15 for bug 1641049

I was able to reproduce this bug in a bit different manner in vagrant VM environment.

We were using 16.04 as nfs server and 14.04, 16.04 (with latest kernel and 4.9-rc6) and 16.10 as clients.

For the testing we were using the script in the end of this post.

Scenario is:
* create 1k symlinks by A on share
* ls that directory
* delete symlinks on A
* create them again on A
* ls the directory again by B
* delete everything

repeat 10 times

Kernels 4.4 (from 16.04) AND 4.8 (from 16.10) have errors like

ls: cannot read symbolic link '/mnt/ubuntu/347': Input/output error
ls: cannot read symbolic link '/mnt/ubuntu/891': Input/output error
ls: cannot read symbolic link '/mnt/ubuntu/248': Input/output error
ls: cannot read symbolic link '/mnt/ubuntu/872': Input/output error

starting from the second ls.

Kernels 3.13 (from 14.04) and upstream 4.9-rc6 do not have these errors.

If you want vagrant files for vms please tell.

Testing script:

#!/bin/zsh

a=9e0147f
b=7329576

function exec_a {
    vagrant ssh -c "/bin/bash -c ${(q)*}" $a -- -q
}

function exec_b {
    vagrant ssh -c "/bin/bash -c ${(q)*}" $b -- -q
}

SHARE_ROOT=/mnt/ubuntu

function iteration {
    exec_a "for i in {0..1000}; do ln -s /dev/null $SHARE_ROOT/\$i ; done"
    exec_b "ls -li $SHARE_ROOT | wc -l | paste <(echo \"first ls\") - "
    exec_a "find $SHARE_ROOT -type l -delete"
    exec_a "for i in {0..1000}; do ln -s /dev/null $SHARE_ROOT/\$i ; done"
    exec_b "ls -li $SHARE_ROOT | wc -l | paste <(echo \"second ls\") - "
    exec_a "find $SHARE_ROOT -type l -delete"
}

exec_a "find $SHARE_ROOT -type l -delete"

for i in {0..10}; do iteration; done