From owner-freebsd-fs@FreeBSD.ORG Fri Jun 9 18:46:51 2006 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90ACD16A41A for ; Fri, 9 Jun 2006 18:46:51 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D09443D77 for ; Fri, 9 Jun 2006 18:46:50 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([69.15.205.254]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k59IkakU039840; Fri, 9 Jun 2006 12:46:41 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4489C206.8020507@samsco.org> Date: Fri, 09 Jun 2006 12:46:30 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <20060609065656.31225.qmail@web30313.mail.mud.yahoo.com> <200606091253.37446.mi+mx@aldan.algebra.com> <4489A8CC.8030307@samsco.org> <200606091313.04913.mi+mx@aldan.algebra.com> <4489AF86.2080901@centtech.com> In-Reply-To: <4489AF86.2080901@centtech.com> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: Mikhail Teterin , fs@freebsd.org Subject: Re: heavy NFS writes lead to corrup summary in superblock X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 18:46:51 -0000 Eric Anderson wrote: > Mikhail Teterin wrote: > >> п'ятниця 09 червень 2006 12:58, Scott Long написав: >> >>> Can you actually measure a performance difference with using the -b >>> 65535 option on newfs? All of the I/O is buffered anyways and >>> contiguous data is already going to be written in 64k blocks. >> >> >> My reasons for using the largest block size was more of the space >> efficiency -- the fs typically holds no more than 20 files in 10 >> directories, but the smallest file is 1Gb in length. This is also why >> I chose ufs1 (-O1) over ufs2 -- we don't need ACLs on this filesystem. >> >> I never benchmarked the speed on the single drives, other than to >> compare with my RAID5 array (which puzzlingly always loses to a single >> drive, but that's a different story). > > > Just curious - what NFS mount options are being used, and are you > changing any sysctl's (vfs/nfs related)? > It's hard to beleive that NFS would be responsible for corrupting the filesystem. You should be able to have a consistent and correct unmount regardless of whether NFS is in use or what options it is using. Scott