Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2188078ybe; Tue, 3 Sep 2019 09:10:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqxtXDaAmLWmgkNgoc1a1K8Ae2/EBZGfOznY9saHBuPd02qIyrOp1oH+x4qFSNRjs2dgsYLm X-Received: by 2002:aa7:800c:: with SMTP id j12mr38938418pfi.255.1567527001811; Tue, 03 Sep 2019 09:10:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567527001; cv=none; d=google.com; s=arc-20160816; b=yCafO4F1dY+fvDFDx1snjfvpGEb/2EPDFk4ikKtlPZbE4qEECZ178YOMWaqhXooRqK xbZHj6y4R9yqg0PiC64fzHaZw9EwEh7Y1XRD9pHqkqlraYcIxHr+ZRXdAKoZP2cE2tEY CGLnQ1eKCT5Tjbw5gFWc6zExko1WnJFPKD+3YVY++Z7/hJ6bfPgljJUgKEErAQ0eprfO 4OX0F5aI73kif7l/jIM9XcEjb8rdcXpHnP47dC3mAXRM63BVUXPR5csCraGJg8COc8Xa dqHsyTs54AP/hrnbZOqXhMMFokk747/nqfrEiRaZ/kA8tSV1BPwVET5laNNLtffMlScx 4ZNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:subject:content-transfer-encoding :mime-version:message-id:date:cc:to:from; bh=sYRJAGwAcQMDamOf1I9c+5ThNXI/fss64vni732HT0o=; b=oEFpsRxMQhC5tkSv6Tb9jgdSTUFohTTRZCFrXqbSsO+cku3Jwb1r+0MPz/dSO3vi7Y ZJwXjUHbtE0lXUHV5vUnbsW/a4VdFRzlVT+4hkF0bk5cYUcnw3hJodYbmH01o4TShWyb wQ26YwqDwhcDUnN1GwFo+t2BenswXBcKMvlh6NO91JNonO/khiJNaopMuC7WC8pmBy4c IboOV+wCewgeFBjwb+kvBlddfzG0/IhdHHhyuCgyyqXkY2NfGft0Jpy1wJoU2LW57UmB CH0jEd7r3qUM+23abxQ7aA5vLxIvA1ay8gALK3A4mvnriyQ3rYnDHEM7J3AIddEcBAjx K7KA== 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 n63si14688493pga.511.2019.09.03.09.09.45; Tue, 03 Sep 2019 09:10:01 -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 S1729974AbfICQIu (ORCPT + 99 others); Tue, 3 Sep 2019 12:08:50 -0400 Received: from tartarus.angband.pl ([54.37.238.230]:46552 "EHLO tartarus.angband.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728679AbfICQIu (ORCPT ); Tue, 3 Sep 2019 12:08:50 -0400 Received: from [2a02:a31c:853f:a300::4] (helo=valinor.angband.pl) by tartarus.angband.pl with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1i5BML-0005on-BJ; Tue, 03 Sep 2019 18:08:47 +0200 Received: from kilobyte by valinor.angband.pl with local (Exim 4.92.1) (envelope-from ) id 1i5BMK-000EhM-Ch; Tue, 03 Sep 2019 18:08:44 +0200 From: Adam Borowski To: Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Adam Borowski Date: Tue, 3 Sep 2019 18:08:40 +0200 Message-Id: <20190903160840.56652-1-kilobyte@angband.pl> X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 2a02:a31c:853f:a300::4 X-SA-Exim-Mail-From: kilobyte@angband.pl X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tartarus.angband.pl X-Spam-Level: X-Spam-Status: No, score=-1.1 required=8.0 tests=BAYES_00=-1.9,RDNS_NONE=0.793, SPF_PASS=-0.001 autolearn=no autolearn_force=no languages=en Subject: [PATCH] Documentation: sysrq: don't recommend 'S' 'U' before 'B' X-SA-Exim-Version: 4.2.1 (built Wed, 08 May 2019 21:11:16 +0000) X-SA-Exim-Scanned: Yes (on tartarus.angband.pl) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. For ext2, any unsafe shutdown meant widespread breakage, but it's no longer a reasonable filesystem for any non-special use. Signed-off-by: Adam Borowski --- Documentation/admin-guide/sysrq.rst | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/Documentation/admin-guide/sysrq.rst b/Documentation/admin-guide/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 consoles. (For example, X or a svgalib program.) -``reboot(b)`` is good when you're unable to shut down. But you should also -``sync(s)`` and ``umount(u)`` first. +``reboot(b)`` is good when you're unable to shut down, it is an equivalent +of pressing the "reset" button. ``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 available. -``sync(s)`` is great when your system is locked up, it allows you to sync 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 rescue +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. -``umount(u)`` is basically useful in the same ways as ``sync(s)``. I generally -``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 place until -you see the "OK" and "Done" message appear on the screen. +``umount(u)`` can be used to mark filesystems as properly unmounted. From the +running system's point of view, they will be remounted read-only. The remount +isn't complete until you see the "OK" and "Done" message appear on the screen. 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 -- 2.23.0