Stale NFS file handles on 8.x amd64

Leon Meßner l.messner at physik.tu-berlin.de
Tue Nov 30 23:17:02 UTC 2010


I set a wrong cc . Please look over to -stable.

Sorry for that,
Leon

On Tue, Nov 30, 2010 at 03:10:18PM +0000, krad wrote:
> On 30 November 2010 01:48, Leon Meßner <l.messner at physik.tu-berlin.de>wrote:
> 
> > Hi,
> >
> > On Mon, Nov 29, 2010 at 08:06:54PM -0500, Adam McDougall wrote:
> > > I've been running dovecot 1.1 on FreeBSD 7.x for a while with a bare
> > > minimum of NFS problems, but it got worse with 8.x.  I have 2-4 servers
> > > (usually just 2) accessing mail on a Netapp over NFSv3 via imapd.
> > > delivery is via procmail which doesn't touch the dovecot metadata and
> > > webmail uses imapd.  Client connections to imapd go to random servers
> > > and I don't yet have solid means to keep certain users on certain
> > > servers.  I upgraded some of the servers to 8.x and dovecot 1.2 and ran
> > > into Stale NFS file handles causing index/uidlist corruption causing
> > > inboxes to appear as empty when they were not.  In some situations their
> > > corrupt index had to be deleted manually.  I first suspected dovecot 1.2
> > > since it was upgraded at the same time but I downgraded to 1.1 and its
> > > doing the same thing.  I don't really have a wealth of details to go on
> > > yet and I usually stay quiet until I do, and half the time it is
> > > difficult to reproduce myself so I've had to put it in production to get
> > > a feel for progress.  This only happens a dozen or so times per weekday
> > > but I feel the need to start taking bigger steps.  I'll probably do what
> >
> > Does it depend on the size of the message?
> >
> > > I can to get IMAP back on a stable base (7.x?) and also try to debug 8.x
> > > on the remaining servers.  A binary search is within possibility if I
> > > can reproduce the symptoms often enough even if I have to put a test
> > > server in production for a few hours.
> > >
> > > Any tips on where we could start looking, or alterations I could try
> > > making such as sysctls to return to older behavior?  It might be worth
> >
> > there were some problems on nullfs mounted nfs shares (like in jails)
> > and dovecot, as dovecot changed its location for temporary file creation
> > to the user home. But IIRC the error message looked more like:
> > http://www.mail-archive.com/dovecot@dovecot.org/msg26856.html
> > And are fixed in stable.
> >
> > Just a hint,
> > Leon
> > _______________________________________________
> > freebsd-questions at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to "
> > freebsd-questions-unsubscribe at freebsd.org"
> >
> 
> 
> im seeing similar issues on a large mail platform with netapp and dovecot on
> freebsd 8.1 as well. The problems existed in 7.x as well though. Basically
> the NFS mount just locks up. I've not managed to pin point it yet but one
> thing im certain of its a client os issue rather than the filer. This is
> because only one node out fo the 16 will lock at any time on that particular
> nfs mount. Strangely as well if I remount the dead nfs share on say /mnt on
> the affected node, it works fine. I'm convinced its some kind of locking
> issue.
> 
> I have dtrace (WITH_CTF=1) in the kernel, so will have a poke around with
> that and see if I can see anything interesting. Can anyone recommend
> anything here?
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"


More information about the freebsd-questions mailing list