From owner-freebsd-stable@FreeBSD.ORG Thu Jul 7 09:24:59 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8943116A41C for ; Thu, 7 Jul 2005 09:24:59 +0000 (GMT) (envelope-from kometen@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29E8543D46 for ; Thu, 7 Jul 2005 09:24:59 +0000 (GMT) (envelope-from kometen@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so161216wri for ; Thu, 07 Jul 2005 02:24:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=nR+5C9dFhg89/l81S8b2ixHVAsQsoz+w3EdtbnqYe/ZdX4B9bifizEh8C8e51O3Ehf/7zPclzJYsVc9E3ZOVyIAjBRhE4OPu8KqZKefQVXzgYkl8i5OizU2oXD2SKIUfr3WkDuox/eRTK1t9SKFVjR/pHJGaR8h8YLL82aqkwbs= Received: by 10.54.34.51 with SMTP id h51mr547757wrh; Thu, 07 Jul 2005 02:24:58 -0700 (PDT) Received: by 10.54.125.12 with HTTP; Thu, 7 Jul 2005 02:24:58 -0700 (PDT) Message-ID: Date: Thu, 7 Jul 2005 11:24:58 +0200 From: Claus Guttesen To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: FreeBSD as nfs-server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Claus Guttesen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2005 09:24:59 -0000 Hi. Last week I phased out my remaining trusty FreeBSD nfs-server. The first was phased out three weeks ago. They have served me well for about two year and I have been *very* satisfied with the performance and stability. The below mentioned reasons made the decision easier to migrate to veritas volume manager on solaris. 1. Lack of a journaling filesystem. 2. Lack of a logical volume manager. My intent is *not* to start a flamewar, simpy stating why I had to migrate. Additional comments to item #1: We have background-fsck, what's wrong with that? Well, there is nothing wrong with that in a way. Background-fsck does work, but my nfs-server have had three unplanned reboots during that time, none of them was caused by the nfs-server itself, but caused by other factors. The server comes back up as it should and detects that the volumes wasn't unmounted in an orderly fashion and defers the volume to background-fsck. So far so good. When the background-fsck is done with one volume and it jumps to the next, my webservers connected to the nfs-server are unable to read and write to the nfs-volumes for a period of 15-30 minutes. The smallest (of several) volume is 400 GB and the largest (of several) is 2 TB. The outcome is that my website is seen as being inaccessible. This was with FreeBSD 5.2 beta through 5.4 I saw this behaviour. So I'm delighted to read that the initial work on a journaling filesystem has started. Additional comments to item #2: Use vinum! Is it vinum or gvinum which is the future of FreeBSD? The docs related to vinum refers to some parameters in newfs not present in the manual-pages. As more volumes are added the task of configuring (g)vinum will become more and more timeconsuming and errorprone. Does it recover correctly in the event of a crash, how about fsck/newfs on volumes larger than 2 TB? The camcontrol program on FreeBSD is a very robust tool. This is one program I miss. Some parameters to the find- and date-commands on FreeBSD aren't there on solaris, so I'll keep the old nfs-server around for doing day2day maintenance. I'm keeping FreeBSD as webservers (of course). regards Claus