Description of problem: When I increased the timeout in md-cache translator to 20 on a single export volume with 2 fuse clients (writing from one client and reading from another), the read output was truncated towards the end of file. Version-Release number of selected component (if applicable): 3.3.0.qa25 How reproducible: Consistently Steps to Reproduce: 1. Client 1: echo 'abc' > dot; 2. Client 2: cat dot 3. Client 1: echo 'sdsdsdnasnfsdnmfsgfds' > dot; 4. Client 2: cat dot Actual results: [root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsds[root@RHEL6 mnt]# cat dot sdsdsdnasnfsdnmfsgfds [root@RHEL6 mnt]# cat dot sdsdsdnasnfsdnmfsgfds Additional info: All other performance translators on the client side were disabled. Client vol file- volume dist-client-0 type protocol/client option remote-host 10.1.11.184 option remote-subvolume /dist1 option transport-type tcp end-volume volume dist-md-cache type performance/md-cache option timeout 30 subvolumes dist-client-0 end-volume volume dist type debug/io-stats option latency-measurement off option count-fop-hits off subvolumes dist-md-cache end-volume
This issue is seen even with the default timeout value of 1. So changing the priority to high.
glusterfs is writing to /dev/fuse correct number of bytes. However fuse-kernel module/vfs is returning only so many number of bytes as shown by st_size of stale entry in md-cache for the file. Probably kernel is relying on the st_size to determine the size of file rather than the number of bytes returned as part of read call. However this can be worked around with md-cache timeout as 0. Hence marking this bug as duplicate of 800833 *** This bug has been marked as a duplicate of bug 800833 ***
Hi Raghu, the issue is seen even with md-cache timeout as 0.