Date: Mon, 13 Feb 2017 04:42:52 +0100 From: Polytropon <freebsd@edvax.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170213044252.f78cb29d.freebsd>