Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
I usually do ctrl-alt-sysrq-S-U-B (for some value of usually associated with debugging) to hopefully minimise corruption.
sync vs. Magic-SRQ-S (Alt-SRQ-S)
Posted Apr 3, 2009 13:41 UTC (Fri) by Duncan (guest, #6647)
I'm a sysadmin level user, not a kernel coder, so I'd actually like to
know that as well.
However, based on the documentation I've read, the Magic-SRQ sequences
were devised by kernel hackers for kernel debugging and consequently
on-disk data stability under the "emergency" conditions often associated
with debugging "first try" code. Thus, it has always been my impression
that while sync is designed for more or less routine use and thus flushes
a layer or two... but may not /always/ flush thru all layers all the way
to disk (and do what it can to trigger the hardware to sync as well), the
Magic-SRQ Alt-SRQ-S sequence is designed for emergency last-resort use by
those who are trying to avoid data loss, serious RAID-resync times, etc.
As such, it has been my belief (based on the documentation but NOT a
reading of the code, with all the caveats that therefore apply) that if
you watch the hardware activity LEDs and actually see a flurry of activity
in response to the Alt-SRQ-S sequence, when it subsides, you have as close
to a guarantee as the kernel can give that it is synced -- at least as
good but from my reading, likely better, than with the sync command.
Of course, in may cases the very Alt-SRQ trigger itself gets syslogged,
meaning the buffer is immediately dirty once again with at /least/ that
syslog entry, so immediately reinvoking the sequence will probably write
at least that. but my observation is that subsequent invokations after the
first trigger far less (unaccounted) activity.
Of course, the S/sync should be followed by the U/remoUnt-read-only, as
you noted, before the reboot.
BTW, you mentioned ctrl-. That key shouldn't be necessary as part of the
sequence, only the Alt-SRQ-<key>. Alt is necessary in this case as part
of the x86 keyboard SRQ hardware design, as updated for 101-key (the
original 84-key keyboards had it as a separate key, not combined with
PrtScr as it is on the later 101-key and variants). Without Alt, it's not
the SRQ key at all, but rather print-screen. Thus, Alt-SRQ is actually a
single code, Alt- being necessary to trigger SRQ at all. As implemented
for Magic-SRQ on Linux, that code puts the kernel into a mode to handle a
letter key pushed with it specially, but it's a two-code combo that simply
happens to require pushing three keys. Ctrl isn't part of either the
Linux implementation (at least for x86 in either 32-bit or 64-bit mode) or
the hardware implementation, so shouldn't be required -- tho it
(obviously) doesn't interfere, either.
The wikipedia System_request entry has a lot more interesting info on the
history and other implemented uses, and can be found here:
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds