[Gluster-devel] NetBSD regression status upate

[Emmanuel Dreyfus]

Sachin Pandit <spandit at redhat.com> 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 at netbsd.org