> -----Original Message----- > From: Clifton Royston [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 03, 2002 8:06 PM > To: Brian L. MacDonald > Cc: Subscribers of Qpopper; Dayv Gastonguay > Subject: Re: Qpopper4.0.4 server mode and NetApp and fstat > > > On Thu, Oct 03, 2002 at 06:51:48PM -0400, Brian L. MacDonald wrote: > > Qpopper 4.0.4 server mode > > Mail spool on NetApp filer via NFS > > > > We have been having a problem that was a bear to track down. > > What's the NFS client's OS (i.e. the server you're running qpopper on)? We are using both True64/OSF1 V4.0F for qpopper and Free BSD 4.4.
> > > When we use server mode we are loosing mail. I know about the > MDA and MUA > > issues and we are only using MDA for these accounts. If we turn on full > > debugging what we are seeing happen is that when a new message > is delivered > > to the mail spool while a qpopper session is active qpopper at > times does > > not realize that the mail spool has been appended and truncates the mail > > spool without first copying any undeleted messages. > > > > If our troubleshooting is correct, the reason this is happening > is that when > > pop_updt.c does a fstat it is seeing the same filesize as when > the session > > started. > > > > The reason for the fstat not being updated from the time when > the session > > started is related to the NetApp. The NetApp caches writes to the > > filesystem. When you perform a fstat on a file you are getting > the stat of > > the file that is on the physical disk which does not include > any writes that > > have occurred that have been cached but not written to disk. > The max amount > > of time that the write can be cached (and qpopper get an > invalid fstat) is > > 30 sec. (I think-trying to verify). > > This sounds like a major bug in either the NetApp or (more likely) > the NFS client's implementation of the NFS stat RPC or (I suspect) a > configuration problem. What NFS-related daemons do you see running on > the qpopper server? Do you see statd running? > Yes, lockd and statd are both running on all the machines. When we are running qpopper without server mode all seems to be well. We are trying to use server mode, and have in the past, for performance advantages. > > Questions: > > 1. Has anyone encountered this problem and if so how have you > got around > > it? > > > > 2. Has anyone attempted or thought of a way to modify qpopper > to look at > > the spool file rather than doing an fstat? > > Should not be necessary. This kind of workaround suggests something > really broken. > > > 3. Has anyone found a way to configure the NetApp to have fstat include > > cached writes? > > If it doesn't do that, it's completely broken as an NFS server, and > I've never heard that about the NetApps. You need to look at whether > statd is running and working right. > I currently have a ticket open with NetApp to unsure this is proper operation. I am hoping that they have a "fix" for this situation. > > 4. Does anyone have any other thoughts as to how to correct > this problem? > > Try googling for some NFS corectness test suites and running them > from the server. That should pinpoint whether everything's working > properly. > Will do some searching. However, locking with mail spools for users that are using MUAs does not appear to be a problem. > Hope this helps, > -- Clifton > -- > Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED] > "What do we need to make our world come alive? > What does it take to make us sing? > While we're waiting for the next one to arrive..." - Sisters of Mercy >
