Date: Mon, 9 Apr 2007 20:40:07 GMT From: Dan D Niles <dan@more.net> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/111146: fsck fails on 6Tfilesystem Message-ID: <200704092040.l39Ke7sb083557@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/111146; it has been noted by GNATS. From: Dan D Niles <dan@more.net> To: Jan Srzednicki <w@wrzask.pl> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200704092040.l39Ke7sb083557>