From owner-freebsd-stable Sat May 25 14: 6: 2 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.allcaps.org (mail.allcaps.org [208.252.245.17]) by hub.freebsd.org (Postfix) with ESMTP id 59EF737B400 for ; Sat, 25 May 2002 14:05:58 -0700 (PDT) Received: by mail.allcaps.org (Postfix, from userid 501) id CF69A32601; Sat, 25 May 2002 14:05:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.allcaps.org (Postfix) with ESMTP id CAB472E81A; Sat, 25 May 2002 14:05:57 -0700 (PDT) Date: Sat, 25 May 2002 14:05:57 -0700 (PDT) From: "Andrew P. Lentvorski" To: Eugene Grosbein Cc: Matthew Dillon , Subject: Re: NFS problem with 4.6-PRERELEASE: SIGBUG in Apache In-Reply-To: <3CEF45CE.396892B3@svzserv.kemerovo.su> Message-ID: <20020525135358.B9226-100000@mail.allcaps.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > So when updating files which might be mmap()'d over NFS, you have to > > be careful not to delete or truncate a file which may be in-use. Two questions: 1) If the file can actually be updated, why isn't Apache robust in the face of this? The fact that the bug pops up on NFS is only a function of a timing race. That race also exists on normal file systems, but with a smaller timing window. 2) Why aren't the programs which are accessing this file putting a lock on it? Generally programs do their "own" file locking because NFS file locking fails on so many platforms. It's possible that Apache does create some sort of locking which is non-standard that gets ignored by other programs. In general, mmap over NFS has "quirks", especially with respect to locking. See "NFS Illustrated" for gory details about interactions between caching/locking and mmap in NFS. -a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message