Re: NFS/RPC 2.2.13 request slot [patch for plptools-0.4]

Olaf Flebbe (o.flebbe@science-computing.de)
Thu, 11 Nov 1999 10:50:49 +0100

> > from an strace of an cp to the mounted dir
>
> > write(5,
> > "\310\223\372|7s\356!\215\245e\301o$\rG\356\36\270\230b"...,
> > 4096) = -1 ENOSPC (No space left on device)
>
> > (The diagnostic is incorrect)
>
> Hmm. Strange...
>
> 1) Does the ordinary NFS client (no amd or plptools) give the same
> error?
> 2) What about 'traceroute -s 256'? (Most versions of traceroute
> should be able to interpret the NFS protocol, and tell you what is
> being sent down the wire.) I'd like to know whether the server
> really is replying ENOSPC, or whether there's a 'translation
> error' somewhere...
>

Unfortunatly one does not see the local NFS traffic with tcpdump. While
looking into the source for further debugging options I found the
solution. The kernel messages: task .. cannot find request slot, are not
so closely related with the ENOSPC as I thought in the beginning. The
plptools NFS server is overrunning the EPOC OS on the palmtop: Someone
else (Maybe it is the GUI) is opening the file and plptools gets a File
Already in Use error which is translated by plptools to the NFS ENOSPC
error. I fixed plptools in order retrying opening this file and now I do
not get the ENOSPC errors any more, and cp works even for large files.
(Patch is sent to Fritz Elfert, the author)

**But the nfs messages into the syslog persists. What can we do against
it? If one gets this error, NFS seems to be very slow. And sometimes one
gets this kind of error with amd, which should be fast enough to fulfill
the requests. **

Cheers
Olaf

*** plptools-0.4.old/plpnfsd/mp_pfs_ops.c Mon Jul 5 23:33:06 1999
--- plptools-0.4/plpnfsd/mp_pfs_ops.c Wed Nov 10 21:10:19 1999
***************
*** 872,877 ****
--- 872,878 ----
struct attrstat *gres;
long phandle;
int len, dlen, doff;
+ int tmp;

if (!inode) {
debuglog("write: stale fh\n");
***************
*** 906,912 ****
res.status = NFS_OK;
return &res;
}
! /* Write out as many blocks from the cache as we can */
for (;;) {
if (debug > 2)
for (dcp = cp->dcache; dcp; dcp = dcp->next)
--- 907,924 ----
res.status = NFS_OK;
return &res;
}
! /* Write out as many blocks from the cache as we can */
!
! while ((tmp = rfsv_fopen(0x200, inode->name, &phandle)) == -14)
{ /* -14
File in use */
! debuglog("write: open failed (trying again)\n");
! }
!
! if (tmp != 0) {
! debuglog("write: open failed: %d\n", tmp);
! res.status = rfsv_isalive() ? NFSERR_NOSPC : NO_PSION;
! return &res;
! }
!
for (;;) {
if (debug > 2)
for (dcp = cp->dcache; dcp; dcp = dcp->next)
***************
*** 922,945 ****
debuglog("writing off: %d, len: %d, act: %d\n",
dcp->offset, dcp->len, cp->actual_size);

- if (rfsv_fopen(0x200, inode->name, &phandle) != 0) {
- debuglog("write: open failed\n");
- res.status = rfsv_isalive() ? NFSERR_NOSPC :
NO_PSION;
- return &res;
- }
if (rfsv_write(dcp->data, dcp->offset, dcp->len,
phandle) != dcp
->len) {

rfsv_fclose(phandle);
dcp->towrite = 0;
len = dcp->offset + dcp->len;
if (len > cp->actual_size)
cp->actual_size = len;
debuglog("written: new length: %d\n", cp->actual_size);
}

debuglog("write -> ISOK (%d, %d %d)\n",
res.attrstat_u.attributes.size,
--- 934,952 ----
debuglog("writing off: %d, len: %d, act: %d\n",
dcp->offset, dcp->len, cp->actual_size);

if (rfsv_write(dcp->data, dcp->offset, dcp->len,
phandle) != dcp
->len) {
rfsv_fclose(phandle);
debuglog("write: dump failed\n");
res.status = rfsv_isalive() ? NFSERR_NOSPC :
NO_PSION;
return &res;
}
dcp->towrite = 0;
len = dcp->offset + dcp->len;
if (len > cp->actual_size)
cp->actual_size = len;
debuglog("written: new length: %d\n", cp->actual_size);
}
+ rfsv_fclose(phandle);

debuglog("write -> ISOK (%d, %d %d)\n",
res.attrstat_u.attributes.size,

-- 
  Dr. Olaf Flebbe                            Phone +49 (0)7071-9457-32
  science + computing gmbh                     FAX +49 (0)7071-9457-27
  Hagellocher Weg 71
  D-72070 Tuebingen  Email: o.flebbe@science-computing.de


      The amount of work to be done increases in proportion to the
                  amount of work already completed.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/