Sachin Pandit <spandit@xxxxxxxxxx> wrote: > In this test case we are writing "content" into the files (fd's). > But for some reason the data "content" is not being written > into the files and because of that quota fails to account the > size. I did some tests and here are the results: # exec 16>/mnt/nfs/0/0/1/2/xxx file gets created empty # echo "content" >&16 kernel trace of the shell shows the data is being written, which means there is no libc buffering. But tcpdump show no data sent over NFS. There is indeed some client kernel cache I was not aware of. Let us try to flush it # (cd $N0; umount $N0 ) tcpdump shows "content" being sent over NFS. Hurrah? Not yet: the file size on the brick is still zero. # exec 16>&- # echo "content" > /mnt/nfs/0/0/1/2/xxx # ls -l /d/backends/brick1/0/1/2/xxx -rw-r--r-- 2 root wheel 0 May 5 01:12 /d/backends/brick1/0/1/2/xxx Data wad sent to server ove NFS, but the file remains empty on the brick. # cat /mnt/nfs/0/0/1/2/xxx (nothing) Reading /mnt/nfs/0/0/1/2/xxx shows no data, which means the lost data is not even cached server side. But here is the explanation: # echo "content" > /mnt/nfs/0/0/1/2/zzz bash: /mnt/nfs/0/0/1/2/zzz: Disc quota exceeded Data is not written because quota is over, but that is not shown for file xxx that was accessed using shell file descriptor. Even more surprising is that the situation continues after the file descriptor was closed. Conclusions: - There is a client cache and the (cd $N0 ; umount $N0 ) trick is good for flushing it - The feature being tested seems broken on NetBSD. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@xxxxxxxxxx _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
