From owner-freebsd-questions Fri Oct 6 14:21:57 1995 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA16605 for questions-outgoing; Fri, 6 Oct 1995 14:21:57 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA16599 for ; Fri, 6 Oct 1995 14:21:51 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02102; Fri, 6 Oct 1995 14:20:11 -0700 From: Terry Lambert Message-Id: <199510062120.OAA02102@phaeton.artisoft.com> Subject: Re: File Corruption Problem To: alan@niceguy.isocor.ie (Alan Byrne) Date: Fri, 6 Oct 1995 14:20:11 -0700 (MST) Cc: freebsd-questions@freefall.freebsd.org In-Reply-To: from "Alan Byrne" at Oct 6, 95 03:43:41 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1611 Sender: owner-questions@FreeBSD.org Precedence: bulk > I'm seeing a strange problem with some files getting corrupted on a > FreeBSD disk. > > The machine in question is running 2.0.5-950622-SNAP. > > I am using it as a News Server, NFS Server, Mail (POP & SMTP) Server, > Samba Server, and for storing some source code with RCS. All work very > well except for the following... > > The problem is with our RCS files, every few days, one or two rcs files > appear with 1024 null characters in it, overwriting a block of valid data > in the file (loads of these - ^@^@^@^@^@^@^) ouch ! > > The RCS tree is NFS mounted on a number of various unix platforms, and > people check-out and check-in the files on these platforms (over NFS). > Could the problem be related to NFS file locking problems, or is it a > symptom of some other form of filesystem corruption. Are you doing potentially simultaneous updates? The problem is that RCS doesn't support this; use CVS instead (it's built on top of RCS). If you get multiple updates, a second problem will surface; there is no NFS lock support, so updates over NFS could interfere with each other (and in fact will cause zero-filled pages if one client updates an area following another clients update of the area just previous). Either use a multiple reader/single writer interface to obtain write access in the first place to prevent collisions, or use the newly released CVS client/server code (get it from the CVS home site; it's in the CVS readme in ports). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.