Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!spool.mu.edu!howland.erols.net!newsfeed.internetmci.com!in3.uu.net!news.alt.net!news1.alt.net!news.serv.net!not-for-mail From: zeno@serv.net (Sean T. Lamont .) Newsgroups: comp.unix.bsd.freebsd.misc Subject: NFS oddify Date: 12 Oct 1996 04:21:57 -0700 Organization: ServNet Internet Services, Seattle, WA Lines: 38 Message-ID: <53nv0l$2sk@itchy.serv.net> NNTP-Posting-Host: itchy.serv.net I"m not sure if this is a bug or not. In the example I have a 2.1.5 system mounting an nfs disk from a 2.1.0 system. cp /kernel /nfs/kernel mv /nfs/kernel /nfs/kernel.old ; cp /kernel /nfs/kernel mv /nfs/kernel /nfs/kernel.old ; cp /kernel /nfs/kernel mv /nfs/kernel /nfs/kernel.old ; cp /kernel /nfs/kernel ...... Each time this is executed, a chunk of disk the size of /kernel is consumed by the system ; I thought it was an open file descriptor by nfsd or mountd, but killing nfsd doesn't seem to free the space. Of course, this above operation doesn't lose anything on the local disk. This is unfortunate, because I'm using something similar to this to manage our password system. removing /nfs/kernel.old before executing 'mv' seems to fix the problem, but this bothers me because rename() is an autonomous operation, and I don't believe you can be left at any point with a nonexistent /kernel.old file. executing unlink() before rename() is close, but there still exists the possibility that the unlink() can be called, and then a process be swapped in which accesses this (nonexistent) file before the rename() is called. I don't believe the memory-leaking example has this possibility. -- -- Sean T. Lamont, President / Chief NetNerd, Abstract Software, Inc. (ServNet) - Internet access * WWW hosting * TCP/IP * UNIX * NEXTSTEP * WWW Development - email: lamont@abstractsoft.com WWW: http://www.serv.net "...There's no moral, it's just a lot of stuff that happens". - H. Simpson