From owner-freebsd-questions@freebsd.org Mon Feb 13 03:42:57 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FB0ACDC0AF for ; Mon, 13 Feb 2017 03:42:57 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mailrelay15.qsc.de (mailrelay15.qsc.de [212.99.187.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.antispameurope.com", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE1CC70 for ; Mon, 13 Feb 2017 03:42:56 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de ([213.148.129.14]) by mailrelay15.qsc.de; Mon, 13 Feb 2017 04:44:24 +0100 Received: from r56.edvax.de (port-92-195-22-222.dynamic.qsc.de [92.195.22.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPS id 278AF3CC3F; Mon, 13 Feb 2017 04:42:53 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id v1D3gqwm002063; Mon, 13 Feb 2017 04:42:52 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Mon, 13 Feb 2017 04:42:52 +0100 From: Polytropon To: perryh@pluto.rain.com (Perry Hutchison) Cc: freebsd-questions@freebsd.org Subject: Re: Bugs in fsck(8) and fsck_ufs(8) Message-Id: <20170213044252.f78cb29d.freebsd@edvax.de> In-Reply-To: <58a12387.at7Hz9kYDc2UvWNn%perryh@pluto.rain.com> References: <58a12387.at7Hz9kYDc2UvWNn%perryh@pluto.rain.com> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-cloud-security-sender: freebsd@edvax.de X-cloud-security-recipient: freebsd-questions@freebsd.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mailrelay15.qsc.de with 3DC3269E7FC X-cloud-security-connect: mx01.qsc.de[213.148.129.14], TLS=1, IP=213.148.129.14 X-cloud-security: scantime:.2053 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 03:42:57 -0000 On Sun, 12 Feb 2017 19:09:59 -0800, Perry Hutchison wrote: > I have a UFS filesystem that will not mount, and it confuses fsck(8): > > # mount /dev/da2p2 /mnt > mount: /dev/da2p2 : Operation not permitted > > # fsck /dev/da2p2 > fsck: Could not determine filesystem type > > Why can't fsck(8) recognize the filesystem type? If I remember correctly, the information for the -t option is taken from /etc/fstab, so when /dev/da2p2 doesn't have an entry in that file, fsck will not automatically select the right type. > To be outdone by file(1) in filesystem type recognition is pretty > clearly a bug in fsck(8), but not a terribly serious one since it > can be gotten around easy enough by running fsck_ufs(8) directly. Or use "fsck -t ufs" plus additional options you might need. > However, fsck_ufs(8) also has trouble with this filesystem: it > claims something is wrong, but it doesn't even identify any specific > problems much less fix them: > > # fsck_ufs /dev/da2p2 > ** /dev/da2p2 > ** Last Mounted on /mnt > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 13527 files, 628739 used, 43580 free (236 frags, 5418 blocks, > 0.0% fragmentation) > > ***** FILE SYSTEM STILL DIRTY ***** > > ***** PLEASE RERUN FSCK ***** Do you have journaling enabled with UFS for that file system? Any other "non-standard" options which might be interfering? > So it seems this filesystem also provokes a bug in fsck_ufs(8): > any problem serious enough to not mark the filesystem as clean > is serious enough to at least report, if not fix. (I've rerun > it several times, always getting the same result.) That indicates a severe problem with the file system. > I'd try falling back to lower-level tools, but it seems they no > longer exist: > > # which icheck > icheck: Command not found. > > # which dcheck > dcheck: Command not found. > > # which ncheck > ncheck: Command not found. > > Now what? A lower-level tool included with the OS is "fsdb". -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...