brain-hackers_pepepper-mirror/linux-brain
1
0
Fork 0
mirror of https://github.com/brain-hackers/linux-brain.git synced 2024-06-09 23:36:23 +09:00
Code Issues Projects Releases Wiki Activity

Documentation: sysrq: don't recommend 'S' 'U' before 'B'

Browse Source 
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 <kilobyte@angband.pl>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Adam Borowski 2019-09-03 18:08:40 +02:00 committed by Jonathan Corbet
parent c193a3ffc2
commit 209c3aa7f0
1 changed files with 9 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
Documentation/admin-guide/sysrq.rst
View File

@ -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. useful when you want to exit a program that will not let you switch consoles.
(For example, X or a svgalib program.) (For example, X or a svgalib program.)
``reboot(b)`` is good when you're unable to shut down. But you should also ``reboot(b)`` is good when you're unable to shut down, it is an equivalent
``sync(s)`` and ``umount(u)`` first. of pressing the "reset" button.
``crash(c)`` can be used to manually trigger a crashdump when the system is hung. ``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. 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 ``sync(s)`` is handy before yanking removable medium or after using a rescue
disks and will certainly lessen the chance of data loss and fscking. Note shell that provides no graceful shutdown -- it will ensure your data is
that the sync hasn't taken place until you see the "OK" and "Done" appear safely written to the disk. Note that the sync hasn't taken place until you see
on the screen. (If the kernel is really in strife, you may not ever get the the "OK" and "Done" appear on the screen.
OK or Done message...)
``umount(u)`` is basically useful in the same ways as ``sync(s)``. I generally ``umount(u)`` can be used to mark filesystems as properly unmounted. From the
``sync(s)``, ``umount(u)``, then ``reboot(b)`` when my system locks. It's saved running system's point of view, they will be remounted read-only. The remount
me many a fsck. Again, the unmount (remount read-only) hasn't taken place until isn't complete until you see the "OK" and "Done" message appear on the screen.
you see the "OK" and "Done" message appear on the screen.
The loglevels ``0``-``9`` are useful when your console is being flooded with 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 kernel messages you do not want to see. Selecting ``0`` will prevent all but