From owner-freebsd-fs Wed Dec 13 0:53:45 2000 From owner-freebsd-fs@FreeBSD.ORG Wed Dec 13 00:53:42 2000 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 4449037B400 for ; Wed, 13 Dec 2000 00:53:42 -0800 (PST) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id BAA10645; Wed, 13 Dec 2000 01:51:23 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp03.primenet.com, id smtpdAAA_RayOu; Wed Dec 13 01:51:09 2000 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id BAA26821; Wed, 13 Dec 2000 01:53:25 -0700 (MST) From: Terry Lambert Message-Id: <200012130853.BAA26821@usr08.primenet.com> Subject: Re: Filesystem tuning (minimize seeks) To: henrich@sigbus.com (Charles Henrich) Date: Wed, 13 Dec 2000 08:53:25 +0000 (GMT) Cc: freebsd-fs@FreeBSD.ORG In-Reply-To: <20001212103851.C20653@sigbus.com> from "Charles Henrich" at Dec 12, 2000 10:38:51 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: tlambert@usr08.primenet.com Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Im trying to tune a FreeBSD box acting as a NFS file server, and was wondering > if anyone had any suggestions on how to handle multiple concurrent writes from > causing the data to be written very non-sequential. Anyone? Thanks! NFS writes are supposed to be sent with the file offset, the length of the data, and the data. The offset is dereferenced from the file structure on the originating machine. Is this aggregating the output of several seperate machines? If so, there will need to be a reconning of the file offset between the machines doing the writing, probably with an out of band protocol of some kind. Most commonly, this is accomplished with token passing, where the reciever of the token seeks to the end of the file and appends after getting the token. If you could provide some more information on what the client machines are doing, and what your desired behaviour is, we could probably give you a better approach. If you are running commercial Linux software, and it's not running on FreeBSD, but runs fine on Linux, then it may be that a cached value of the file status information is being used, and a fix needs to be applied to NFS to ensure that it has up to date information from the server before doing the seek (e.g. the stat that precedes the seek may not result in wire traffic, when it should). There are several reasons this could fail, including, but not limited to, missing LEASE revocation operations that should invalidate client cached state. NFS doesn't really guarantee distribute coherency like this, it's really a client issue. If you are using NFS locking, well, FreeBSD does not currently enforce this properly (though there is BSDI code that is supposedly available, which could probably be integrated to rectify the locking situation). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message