From owner-freebsd-fs@FreeBSD.ORG Wed Mar 14 22:13:40 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0507D16A4CB for ; Wed, 14 Mar 2007 22:13:40 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (noop.in-addr.com [208.58.23.51]) by mx1.freebsd.org (Postfix) with ESMTP id 980DC13C457 for ; Wed, 14 Mar 2007 22:13:39 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1HRbRy-0002q9-PP; Wed, 14 Mar 2007 17:56:02 -0400 Date: Wed, 14 Mar 2007 16:56:02 -0500 From: Gary Palmer To: Stan Behrens Message-ID: <20070314215602.GB32936@in-addr.com> Mail-Followup-To: Stan Behrens , freebsd-fs@freebsd.org References: <45F41514.1090304@kon.de> <45F84B8C.5030209@freebsd.org> <45F85F1B.8050309@kon.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45F85F1B.8050309@kon.de> Cc: freebsd-fs@freebsd.org Subject: Re: fsck_ufs: cannot alloc %u bytes for inoinfo 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: Wed, 14 Mar 2007 22:13:40 -0000 On Wed, Mar 14, 2007 at 09:46:19PM +0100, Stan Behrens wrote: > Thanks for that hint. > > But it's not the dataloss which runs me writing here, it's this 3570453704 > bytes (means 3.3 gigabytes of ram) it tries to alloc what confuses me. Don't be confused. You completely overwrote at least one cylinder group and probably the direct/indirect blocks relating to the root inode. Overwriting the CG alone is enough to make the fs unrecoverable through fsck, the further damage just adds more nails to the coffin. All that the error means is that fsck tried to read in the cylinder group, got a garbage value for the number of inodes in use and tried to allocate enough memory to handle that. Could fsck_ffs be smarter about recovering from this? Possibly. However, recovering a filesystem that go so thoroughly toasted is better left to specialised data recovery tools. Regards, Gary