Date: Thu, 03 Apr 2014 12:58:17 -0700 From: "Ronald F. Guilmette" <rfg@tristatelogic.com> To: freebsd-questions@freebsd.org Subject: Re: A question about fsck and the -t option Message-ID: <6434.1396555097@server1.tristatelogic.com> In-Reply-To: <533CE084.2060509@cyberleo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <533CE084.2060509@cyberleo.net>, CyberLeo Kitsana <cyberleo@cyberleo.net> wrote: >On 04/02/2014 06:00 PM, Ronald F. Guilmette wrote: >> I shall be filing a documentation PR on this, because I'm a firm believer >> that important aspects of behavior should be documented. > >Excellent idea. Done. http://www.freebsd.org/cgi/query-pr.cgi?pr=188214 >>> It does not appear to >>> attempt a guess from the filesystem magic itself. >> >> Should it perhaps do so? > >I don't think so. Magical behaviour can be the source of much strife. In general, I agree with that sentiment, however there is something to be said for software design that is intelligent enough to do what the user intended, without a lot of fussing. >Precisely what is fsck supposed to do if you create a zpool on a disk >without first erasing the ufs magic therefrom, or vice versa, for example? Not thinking too deeply about this, my answer would be that if there is a ufs filesystem present, then performing an "fsck_ufs" operation thereupon would not be likely to cause any harm. I confess however to my own near total ignorance about zpools. So I have no idea how (or whether) that might affect the picture. >> Also and separately, please correct me if I am wrong, but aren't BSD style >> partition labels going the way of the dinosaur, now that we have GPT >> partitioning available? > >Not until GPT stops causing unintended consequences with older machines >and poorly implemented firmwares. A fair point. (Life would be so much simpler if software never had to cater to legacy hardware. 'Tis a thing much to be yearned for.) Regards, rfg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6434.1396555097>