From owner-freebsd-questions@freebsd.org Wed Apr 22 01:33:29 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2CABD2C12CF for ; Wed, 22 Apr 2020 01:33:29 +0000 (UTC) (envelope-from jguojun@gmail.com) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 496NHX2dgbz4VHV for ; Wed, 22 Apr 2020 01:33:28 +0000 (UTC) (envelope-from jguojun@gmail.com) Received: by mail-oi1-x242.google.com with SMTP id m14so556698oic.0 for ; Tue, 21 Apr 2020 18:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=+96CHpq63QcSVmHazKzBWTFkE0W0ttBUvyaMF17At7k=; b=u452BS9xrpPclLwHEaw5hPlkYfKyl52bc2NzqewJ5jzV+V/VTattDuz5IdlDYm0x2R mqXNT6yLeADdWRHiffA5lLEtKb6CzZB4FWHAqzbMhV4z4kPm6p4iVmJmUYqcTYao0zEH AZJCQsVOphaYGnCCH+Ph68iS82zGwSpA2rLFvFd+m6vscLC6cy2tT5bv3eYBRT4+hK2D 2mHT+sW6DDYL9Lay1EfBiv4R/z8peCfDarS5R3tnfcgqqeKR2ylMWmQPsW3Dzqzik0dN NwIL3ycxNp0sumy15UaexYWb455djqwAOsN0rkxSl7pTXYHZhAP7TPg1qeF9kRijUN0U /cIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=+96CHpq63QcSVmHazKzBWTFkE0W0ttBUvyaMF17At7k=; b=Vsd8YwVAFB/nfwZocmoHxNrFUlM2XaDO9x/fTxtyaFIdaZKed7X1FDBQQxX/El9NPC 7C6niVLszH3eoY9xts5sTB3deuUc9F1c+Wv114WPqcmsgUvS9rxZvYHlTOc+PsyM1vsS sTks2sgNeQwx8nrxHX2obWr+G2Nb3eIsC86UNyX/9ApCiELfTEEqb0D/xECiedl48/Qj hACSHNOMOGcBEo3L9JwtiXxXyeWayg+I0BxRarTohIoviwctvVOzx1TiHQjrayHYlzhG MVp3Vmae7XtFvqBLOzNoLdeY/63u6M60po46bcjAXzfIcYx31kB+++EulXEHsa0pciYj Bxjw== X-Gm-Message-State: AGi0Pua+iGI6BGEnCZM1E2cgOct3vXk2pOipRoVz790jropyMP024sy9 SzYOxzgnoExcuVf6lBeTUHRBGJ0= X-Google-Smtp-Source: APiQypL25PNTbghTMMF+tcBwTLSUUbiJVDUeXd4iHE1QNPqEtxCSZS3aA7F8nOuJIvEX5MXIGFEHiA== X-Received: by 2002:aca:f50e:: with SMTP id t14mr5061054oih.156.1587519206876; Tue, 21 Apr 2020 18:33:26 -0700 (PDT) Received: from [192.168.1.82] (162-239-0-170.lightspeed.sntcca.sbcglobal.net. [162.239.0.170]) by smtp.gmail.com with ESMTPSA id 69sm1186485otv.8.2020.04.21.18.33.25 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 18:33:26 -0700 (PDT) Subject: Re: Should fsck honour "failok" in fstab as mount does? To: freebsd-questions@freebsd.org References: <20200421071319.GA98163@thismonkey.com> <20200421153144.d45a889b.freebsd@edvax.de> <20200421135406.GA74559@thismonkey.com> <20200421160939.aa2fbd89.freebsd@edvax.de> <20200421143321.GA33168@thismonkey.com> <20200421170313.16d4235e.freebsd@edvax.de> <20200421155812.GA54069@thismonkey.com> <20200421182426.45473fbd.freebsd@edvax.de> <20200421215542.GB98882@neutralgood.org> From: "Jin Guojun[VFF]" Message-ID: <483e5a42-0bbc-ff00-1c26-3c26ef45762e@gmail.com> Date: Tue, 21 Apr 2020 18:33:20 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20200421215542.GB98882@neutralgood.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 496NHX2dgbz4VHV X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=u452BS9x; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jguojun@gmail.com designates 2607:f8b0:4864:20::242 as permitted sender) smtp.mailfrom=jguojun@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(0.00)[ip: (0.12), ipnet: 2607:f8b0::/32(-0.33), asn: 15169(-0.43), country: US(-0.05)]; RCVD_IN_DNSWL_NONE(0.00)[2.4.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2020 01:33:29 -0000 On 04/21/20 14:55, Kevin P. Neal wrote: > On Tue, Apr 21, 2020 at 06:24:26PM +0200, Polytropon wrote: >> Right. The problem with changing a keyword's meaning could >> lead to confusion for admins who _expect_ a certain behaviour. >> So maybe new optional keywords would be the better way to go. >> So existing configurations just won't notice, and new settings >> can be added if desired. >> >> Another possibility would be a keyword named "optional", >> so when the filesystem exists && is clean && can be mounted, >> it will be accessible; if not, errors at any stage will not >> interrupt the mount process. It would probably be a good >> idea to have /etc/rc.d/fsck output a warning to the system >> log file in such a case, so the admin _can_ perform checks >> and repair if it should be needed. > Is it useful to have an fstab option that means "fsck MUST succeed! But > mount doesn't have to."?? Personally, I'm not seeing it. If I had noticed > "failok" myself I might have assumed it also applied to fsck. > > Ok, the man page does say it is processed by "mount" and doesn't mention > any other program. But I don't see how it makes sense to have an option > that allows a broken system to come up but only if the brokenness is caught > by mount and not fsck. Agreed with failok option for mount should also apply to fsck. Also, in a sequential operations for the same type of device, the falling into the single user mode should happen in the last step; in this case, the mount daemon. Since mount daemon can determine what file systems it needs, it guides boot-up process for the system, thus no reason for fsck to kill the boot process earlier. If fsck sees a failure, and drops system into single user mode, then failok option in fstab is unlikely useful. For below file system, the /scratch partition is not required. System will run well even if it is missing. User or admin can replace the failure drive later, then, why let system down till this problem fixed? /dev/ada1s1a    /                    ufs     rw       1       1 /dev/ada1s1b    none            swap    sw      0       0 ... /dev/ada0s4d    /scratch         ufs     rw,failok      2       2