From owner-freebsd-bugs@FreeBSD.ORG Tue Jun 28 11:10:23 2005 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FDB416A41C for ; Tue, 28 Jun 2005 11:10:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EE8643D1D for ; Tue, 28 Jun 2005 11:10:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5SBANn4076581 for ; Tue, 28 Jun 2005 11:10:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5SBAMEB076580; Tue, 28 Jun 2005 11:10:23 GMT (envelope-from gnats) Date: Tue, 28 Jun 2005 11:10:23 GMT Message-Id: <200506281110.j5SBAMEB076580@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Bruce Evans Cc: Subject: Re: bin/82720: <[patch] Incorrect help output from growfs.c and mkfs.c> X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Evans List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2005 11:10:23 -0000 The following reply was made to PR bin/82720; it has been noted by GNATS. From: Bruce Evans To: "David D.W. Downey" Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: bin/82720: <[patch] Incorrect help output from growfs.c and mkfs.c> Date: Tue, 28 Jun 2005 21:09:11 +1000 (EST) On Tue, 28 Jun 2005, David D.W. Downey wrote: > My rationale behind setting the Priority to serious is that if you do not > know about fsck_ffs (which can be expected since the default and most known > tool is fsck) then you will run into the issue of not knowing what to do to > repair the broken system. The bug was introduced when the old fsck was renamed to fsck_ffs and fsck became a different program (a wrapper that selects a file-system-specific fscks). This PR shows that the wrapper doesn't handle options very well. > Case in point, I ran into this problem when a -CURRENT system was unable to > repair the default superblock. It kept spitting out FREE BLOK COUNT(S) WRONG > IN SUPERBLOCK. SALVAGE? [no]. Needless to say I spent probably 45 minutes > digging through the man pages such as fsck, bread, sbread, sbwrite, several > lib pages, et cetera trying to figure out how to find info about the next > superblock in order to fix the situation. It actually is described in fsck(8). The -T option can be used to pass flags to file-system-specific fscks. This works like the -o option for mount(8) except it is much more general despite less need for generality, and thus is much harder to use: for mount, where you would say mount -t -o and have all (?) options passed to the mount utility for each selected fstype whether you want this or not, for fsck you can say mount -T: -T: ... You can also say fsck -t but there is nothing corresponding to mount -o for fsck. (Note that multiple fstypes are sometimes useful although not for fsck -b, erm fsck_ffs -b, since they can be used to select a subset of all file systems in /etc/fstab for mount -a and fsck .) > Now I'm just one person. Think of the affect on say just 5,000 people > worldwide with this issue, finally finding newfs only to find out the > information it gives is incorrect. Now add in the fact there's no mention of > fsck_ffs which _is_ the right tool to fix the SB using the SB info spit out > by newfs. There's no logical connection to the correct tool, leaving people > stranded. Small item, this patch, but big help for administrative flow and > repair. I think the "right" tool is still fsck (with -T). However, this is even harder to use than might first appear. Where for "mount -t" the fstype to use is the actual kernel fstype whose mispelling for the ffs file system is well known, the fstype for "fsck -T" is the one in the disk label for the partition (if any (*)). "ffs" is misspelled "ufs" in the kernel, so to mount(8) an ffs file system, you say "mount -t ufs ...". (Similarly for other utilities that use getvfsbyname(3), e.g., "find -t ufs".) For fsck, the the spelling of the file system is normally (*) taken from the disk label, and the "ffs" is usually mispelled "4.2BSD" there, so you have to say something like "fsck -T4.2BSD:..." to run fsck on ffs file systems and pass options. (fsck does some simple transformations of the typename, so you can also say "fsck -T4.2bsd:...", but fsck doesn't have a dictionary of misspellings so neither the "ffs" nor its usual misspelling are transformed to or from "4.2BSD".) For passing the -b option, quoting is probably needed, so the "right" way ends up as something like: fsck -T4.2BSD:"-b 64" Ugh. It's easier to describe and use the method in your patch. (*) The fsck wrapper also fails if there is no disk label or other metadata to give the fstype. In such cases, I don't know how to make it exec the file-system-specific fsck so I just use the f-s-s fsck directly. Anyway, perhaps your PR should be changed/enlarged to one about unclear documentation in fsck.8. Bruce