I have encountered some perplexing behaviour with the nfs server when
using XFS + DMAPI to simulate slow operations.
Using DMAPI I have arranged for the file "a" to block for 60 seconds
before allowing the read to continue. The file "b" is a regular file.
The filesystem is exported as
/fs (rw)
and is mounted on the single Linux client as
server:/fs (rw,addr=??.??.??.??)
I open two windows on the client and issue the following commands:
window1: cd /fs
window1: cat a
window2: cd /fs
window2: cat b
window1: # blocks for ~ 60 seconds
window1: <cat output from a>
window2: <cat output from b>
The reason I am perplexed is the delay to the output from file "b".
Is this the expected behaviour? And is there any way to avoid it?
The server system is running Red Hat Linux 9 for Intel with the
following RPMs:
kernel-2.4.20-19.9.XFS1.3.0.i686.rpm
nfs-utils-1.0.1-3.9.i386.rpm
xfsprogs-2.5.6-0.i386.rpm
dmapi-2.0.8-0.i386.rpm
dmapi-devel-2.0.8-0.i386.rpm
The server is started with
daemon rpc.nfsd 8
and ps(1) shows eight server threads.
If there is any further information I can supply to diagnose this,
please let me know ...
Many thanks in anticipation
--
John Connett
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Thu, 25 Sep 2003 [email protected] wrote:
> If there is any further information I can supply to diagnose this,
> please let me know ...
The two standard tools (and forgive me if I repeating something you've
already tried) would be strace and tcpdump. The former would see which
system call is the sore spot, the latter would trace the network
traffic between client and server.
--Paul Heinlein <[email protected]>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
[email protected] wrote:
> On Thu, 25 Sep 2003 [email protected] wrote:
>
> > If there is any further information I can supply to diagnose this,
> > please let me know ...
>
> The two standard tools (and forgive me if I repeating something you've
> already tried) would be strace and tcpdump. The former would see which
> system call is the sore spot, the latter would trace the network
> traffic between client and server.
Fair comment!
Using strace(1) to trace the system calls issued by the two processes
showed that "cat a" blocked in read() and "cat b" blocked in open().
Examining the NFS packet between client and server using Ethereal
shows that the connections from both processes used the same ports:
2049 (nfs) and 797.
I left the information off of the previous message just in case the
answer was obvious to those in the know ...
Thanks for the swift response
--
John Connett
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs