[PATCH] Documentation: sysrq: don't recommend 'S' 'U' before 'B'

[PATCH] Documentation: sysrq: don't recommend 'S' 'U' before 'B'

[Adam Borowski]

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>
---
 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

Re: [PATCH] Documentation: sysrq: don't recommend 'S' 'U' before 'B'

[Jonathan Corbet]

On Tue,  3 Sep 2019 18:08:40 +0200
Adam Borowski <kilobyte@angband.pl> 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.
> 
> 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>

Makes sense to me.  Applied, thanks.

jon

Re: [PATCH] Documentation: sysrq: don't recommend 'S' 'U' before 'B'

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 3260 bytes --]

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 longer
> a reasonable filesystem for any non-special use.
> 
> Signed-off-by: Adam Borowski <kilobyte@angband.pl>
> ---
>  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

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH] Documentation: sysrq: don't recommend 'S' 'U' before 'B'

[Adam Borowski]

On Mon, Sep 09, 2019 at 10:33:31AM +0200, Pavel Machek wrote:
> 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.

Well yeah, but that's only if you have a reason to suspect there's some data
you care about.  I'd say that in the usual case, saving whatever volatile
state the system has tends to be not worth risking corruption.

Ie, the default advice for a locked-up system should be SysRq B.

Is there some other wording that you would be happier with?

> > 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>
> > ---
> >  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


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ I was born a dumb, ugly and work-loving kid, then I got swapped on
⠈⠳⣄⠀⠀⠀⠀ the maternity ward.