Messages in this thread | | | Date | Thu, 11 Nov 1999 10:50:49 +0100 | From | Olaf Flebbe <> | Subject | Re: NFS/RPC 2.2.13 request slot [patch for plptools-0.4] |
| |
> > 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/
| |