From owner-freebsd-questions@FreeBSD.ORG Fri Aug 29 21:20:31 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4FDB1065672 for ; Fri, 29 Aug 2008 21:20:31 +0000 (UTC) (envelope-from derek@csolve.net) Received: from balrog.csolve.net (balrog.csolve.net [207.164.80.179]) by mx1.freebsd.org (Postfix) with ESMTP id 94E068FC1F for ; Fri, 29 Aug 2008 21:20:31 +0000 (UTC) (envelope-from derek@csolve.net) Received: from alpha.csolve.net ([10.10.18.126]) by balrog.csolve.net with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KZAvj-000AyT-B5 for freebsd-questions@freebsd.org; Fri, 29 Aug 2008 16:50:51 -0400 Message-Id: <3099DB76-6B35-46D7-8875-DC1CA462C71D@csolve.net> From: Derek Buttineau To: freebsd-questions@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v928.1) Date: Fri, 29 Aug 2008 16:50:51 -0400 X-Mailer: Apple Mail (2.928.1) X-Authenticated-Id: test Subject: NFS and File Over Write Performance X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2008 21:20:31 -0000 Just curious if anyone has run into this before. We are testing an HP DL380 G5 Storage Server. The odd thing I'm experiencing is when over writing a file on the NFS share with the FreeBSD NFS client my transfer speed is about 1/3 of what it is if I'm creating a new file on the share. This is all over a 1Gb link and I'm using clpbar to monitor speeds on the copy. From my tests, initial file creation gets me about 89MB/s, while overwriting gets me about 25MB/s The same test using RHEL4 as the client gives a consistent 79MB/s for creation and overwrite. Seems very strange and I've tested from FreeBSD 6.2, 6.3 and 7.0, all with the same results. Any thoughts? Thanks, Derek