Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4817334ybe; Mon, 9 Sep 2019 15:19:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqzqSI1vy13kTVnIZ97FlY6xYlJSzJYetAmBYwzSyfsoMiSNYhBoasuVYgiLRZD0y+TvAMel X-Received: by 2002:a17:906:d78d:: with SMTP id pj13mr21886893ejb.62.1568067563673; Mon, 09 Sep 2019 15:19:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568067563; cv=none; d=google.com; s=arc-20160816; b=VC8klR1EbQnYAE7v1+3KE/i7khI2N5NRnJ2cr/ONlDJr/krIXzBfpO1SLmmkZSQnng CVw9NOGFfgBF4wY6tV+CiFZatPYQxMcetwuGE29jdabwayVfTsVGFoPdy+IL+NHALdDw eHaOjiydxq2PyIsUc7Fi6OO+t468sh7gqrUS0hOQ+snzlDedXhPZIbxpQwW1NB4VuL5D iCLF/fHvVOSga9ZcOHNJ2xAUIFjovYKBdFKdZQGyR7HA9e/I9zMPz+x1fXcHQgkeyaXN ytt4shvFhAh45OkxTFKojn/Ij1b/mb80AiGtyiIuTUDJLc+V2Q1xKqz1dS37JvvKvoWu g0xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=oTGMWo07NxYyV9PLrk3OK47UM3SRJ8jc/EH4KELNkmI=; b=CkazObKJptqU0RlUIm8DmBsc7CVE2nhIiTPS/ncl/8gLkWuUb8yp/dcibNor/Z95Un UcZaY+xkITH6EbTOjgOURm3bz6Px6ZASrlX0G/WjCiwhO5ljAk2hk4/kv5HfWA7CG6FI oRYvGDOZZp6h+JEMWHEMMPHQN1JD66qwF3+2o2YamG5OEAzV2cfu5kNds7BwguGV8xWV WkZRKgY3JN8+/6GZm0djiGUFwCq9QuG4ypFT56R9w2rRfCW7XaCcVnRix+Q8jYI56f9D tBadD2dfuo7FQii6qhWsatjuQiikEKTSXYLACIbhZk+B3yuaAKgFNsFFAKFVcC8KbfTi +RsQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v57si10368354edc.171.2019.09.09.15.18.59; Mon, 09 Sep 2019 15:19:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389295AbfIIIdg (ORCPT + 99 others); Mon, 9 Sep 2019 04:33:36 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:43954 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726302AbfIIIdf (ORCPT ); Mon, 9 Sep 2019 04:33:35 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id 6F7C680868; Mon, 9 Sep 2019 10:33:18 +0200 (CEST) Date: Mon, 9 Sep 2019 10:33:31 +0200 From: Pavel Machek To: Adam Borowski Cc: Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Documentation: sysrq: don't recommend 'S' 'U' before 'B' Message-ID: <20190909083331.GA27626@amd> References: <20190903160840.56652-1-kilobyte@angband.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <20190903160840.56652-1-kilobyte@angband.pl> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue 2019-09-03 18:08:40, Adam Borowski wrote: > This advice is obsolete and slightly harmful for filesystems from this > millenium: any modern filesystem can handle unexpected crashes without > requiring fsck -- and on the other hand, trying to write to the disk when > the kernel is in a bad state risks introducing corruption. Actually no, I don't think it is good idea. sync is still useful these days -- you want the current data to be written to disk; true, you'll not have to do fsck, but you may lose your current data. Best regards, Pavel > For ext2, any unsafe shutdown meant widespread breakage, but it's no long= er > a reasonable filesystem for any non-special use. >=20 > Signed-off-by: Adam Borowski > --- > Documentation/admin-guide/sysrq.rst | 20 +++++++++----------- > 1 file changed, 9 insertions(+), 11 deletions(-) >=20 > diff --git a/Documentation/admin-guide/sysrq.rst b/Documentation/admin-gu= ide/sysrq.rst > index 7b9035c01a2e..72b2cfb066f4 100644 > --- a/Documentation/admin-guide/sysrq.rst > +++ b/Documentation/admin-guide/sysrq.rst > @@ -171,22 +171,20 @@ It seems others find it useful as (System Attention= Key) which is > useful when you want to exit a program that will not let you switch cons= oles. > (For example, X or a svgalib program.) > =20 > -``reboot(b)`` is good when you're unable to shut down. But you should al= so > -``sync(s)`` and ``umount(u)`` first. > +``reboot(b)`` is good when you're unable to shut down, it is an equivale= nt > +of pressing the "reset" button. > =20 > ``crash(c)`` can be used to manually trigger a crashdump when the system= is hung. > Note that this just triggers a crash if there is no dump mechanism avail= able. > =20 > -``sync(s)`` is great when your system is locked up, it allows you to syn= c your > -disks and will certainly lessen the chance of data loss and fscking. Note > -that the sync hasn't taken place until you see the "OK" and "Done" appear > -on the screen. (If the kernel is really in strife, you may not ever get = the > -OK or Done message...) > +``sync(s)`` is handy before yanking removable medium or after using a re= scue > +shell that provides no graceful shutdown -- it will ensure your data is > +safely written to the disk. Note that the sync hasn't taken place until = you see > +the "OK" and "Done" appear on the screen. > =20 > -``umount(u)`` is basically useful in the same ways as ``sync(s)``. I gen= erally > -``sync(s)``, ``umount(u)``, then ``reboot(b)`` when my system locks. It'= s saved > -me many a fsck. Again, the unmount (remount read-only) hasn't taken plac= e until > -you see the "OK" and "Done" message appear on the screen. > +``umount(u)`` can be used to mark filesystems as properly unmounted. Fro= m the > +running system's point of view, they will be remounted read-only. The re= mount > +isn't complete until you see the "OK" and "Done" message appear on the s= creen. > =20 > The loglevels ``0``-``9`` are useful when your console is being flooded = with > kernel messages you do not want to see. Selecting ``0`` will prevent all= but --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAl12DlsACgkQMOfwapXb+vKfWQCfSk//T5/EfUVNB7DboM8KBRSe gTYAnArx0zEgZSiQZ3Tu+m8ljpitMu0p =bG3h -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR--