From owner-freebsd-fs@FreeBSD.ORG Mon Feb 9 20:54:30 2015 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49CAE20A for ; Mon, 9 Feb 2015 20:54:30 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB1DFD69 for ; Mon, 9 Feb 2015 20:54:29 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t19KsDHR014351; Mon, 9 Feb 2015 12:54:17 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201502092054.t19KsDHR014351@gw.catspoiler.org> Date: Mon, 9 Feb 2015 12:54:13 -0800 (PST) From: Don Lewis Subject: Re: Panic during fsck in bhyve VM To: wjw@digiware.nl In-Reply-To: <54D8D4F9.9070901@digiware.nl> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-fs@FreeBSD.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 20:54:30 -0000 On 9 Feb, Willem Jan Withagen wrote: > On 9-2-2015 16:09, Benjamin Kaduk wrote: >> On Mon, 9 Feb 2015, Willem Jan Withagen wrote: >> >>> Hi, >>> >>> Probably due to too many hard-resets of the VM, but I've got the >>> root fs of one of my VMs in a real bad state..... >>> Even where recovery with fsck does not lead to the wanted result. >>> >>> Recovering might be interesting, but not essential since it is just >>> a testing image. >>> >>> The traceback is below. I've saved the image, en getting it online >>> is real easy. >>> >>> If this helps in getting UFS/fsck bugs fixed, I'll keep it. >>> Otherwise it is going into /dev/null >>> >>> --WjW >>> >>> >>> WARNING: WITNESS option enabled, expect reduced performance. >>> Trying to mount root from ufs:/dev/vtbd0p2 [rw]... >>> WARNING: / was not properly dismounted >>> Enter full pathname of shell or RETURN for /bin/sh: >>> # fsck / >>> ** /dev/vtbd0p2 >>> >>> USE JOURNAL? [yn] y >>> >>> ** SU+J Recovering /dev/vtbd0p2 >>> ** Reading 33554432 byte journal from inode 4. >>> >>> RECOVER? [yn] y >>> >>> ** Building recovery table. >>> ** Resolving unreferenced inode list. >>> ** Processing journal entries. >>> >>> ***** FILE SYSTEM MARKED CLEAN ***** >>> # df >>> Filesystem 512-blocks Used Avail Capacity Mounted on >>> /dev/vtbd0p2 30450552 15277136 12737376 55% / >>> devfs 2 2 0 100% /dev >>> # mount -rw / >>> panic: ufs_dirbad: /: bad dir ino 1364363 at offset 512: mangled >>> entry >> >> This does not seem consistent with the subject line of the email. >> >> The first thing to try is to run fsck without using the journal. > > Oke, > > You are correct that I worded the title badly. > The system actually crashes right away after fsck and going to R/W for > the disc. > > I appreciate the input to running without journal. > But there is very little I can find in the manualpages about that? > fsck or fsck_ufs. fsck is fine > But I would expect fsck "to do the smart thing", and report errors > during fixing. And otherwise return a correct FS. If you tell fsck to use the journal, it assumes that the filesystem is basically in good shape and it just needs to take care of the transactions in the journal. That way the the reboot is much quicker because it doesn't have to wait for a full fsck.