From owner-freebsd-bugs@FreeBSD.ORG Mon Apr 9 20:40:08 2007 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 053F616A400 for ; Mon, 9 Apr 2007 20:40:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id ADE4913C45E for ; Mon, 9 Apr 2007 20:40:07 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l39Ke7B6083558 for ; Mon, 9 Apr 2007 20:40:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l39Ke7sb083557; Mon, 9 Apr 2007 20:40:07 GMT (envelope-from gnats) Date: Mon, 9 Apr 2007 20:40:07 GMT Message-Id: <200704092040.l39Ke7sb083557@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Dan D Niles Cc: Subject: Re: bin/111146: fsck fails on 6Tfilesystem X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dan D Niles List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2007 20:40:08 -0000 The following reply was made to PR bin/111146; it has been noted by GNATS. From: Dan D Niles To: Jan Srzednicki Cc: bug-followup@FreeBSD.org Subject: Re: bin/111146: fsck fails on 6Tfilesystem Date: Mon, 09 Apr 2007 15:30:23 -0500 On Mon, 2007-04-09 at 22:13 +0200, Jan Srzednicki wrote: > That's kinda strange, dumpfs never did that to me. It appears to me > that > this filesystem has got quite severely corrupted. Did you try newfs on > it? Not yet. I'd like to figure out why I can't fsck it first. Running newfs on your backup disk is not a viable solution. There is data I cannot pull of the disk. If my primary storage had crashed also, I'd be hosed. > And another thing: try tuning up the -i, -f and -b parameters to > newfs. > I assume that on such a big filesystem average filesize will be much > bigger than the "UNIX default" (10k), so you can safely set these to > their maximums (and allocate inodes more scarcely). Running df reports 8683374 inodes used and 784218256 free. This could be wrong since the filesystem is dirty and mounted ro. FreeBSD's newfs scales things automatically, though perhaps not enough: tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time