Причины CTRL + PrtScr + R + E + I + S + U + B
См. Мое Подробное решение здесь . Ваше решение будет примерно таким же. Что вам нужно сделать иначе, так это использовать несколько Cmnd_Alias , чтобы упростить отладку и добавление новых команд. Вы можете использовать эти несколько строк псевдонимов в сочетании с оператором Negate, как указал DarkHeart в своем ответе.
Я не думаю, что Ctrl+PrtScrмногого даст, вам нужно SysRq(, как правило, на той же физической клавише, что и PrtScr, доступ к которой можно получить, удерживая Altпри нажатии этой клавиши, по этой причине это немного неясно, являются ли «волшебные» комбинации на самом деле SysRq+<letter>илиAlt+SysRq+<letter>).
Функция Bбудет b разгружать систему, так что ваша комбинация — пустая трата времени, только Bкогда-либо будет выполнена, а простая загрузка так же плоха, как и включение и выключение питания.
Что может (иногда )получить поSysRq+R,E,I,S,U,B(мне +указывает на то, что нужно нажимать все клавиши сразу, а нажимать сразу восемь клавиш тяжело и не то, что вы хотите сделать -и обратите внимание, что «BUSIER» на самом деле является классической комбинацией полностью задом наперед ), это более приятное завершение работы, при котором как можно больше данных записывается на диск (s )красиво, поэтому fsck не требуется. при следующей загрузке, и риск потери данных сведен к минимуму.
Много информации, включая полный список комбинаций SysRq -и некоторые мнемоники на странице в Википедии для Magic SysRq .
What are the details of this and is it true to say that Linux is less resilient that MS-Windows in this case?
Было бы полезно провести сравнение в какой-то момент. Это сравнение, вероятно, объясняет, почему эти команды SysRQ так хорошо известны. Однако это неприменимо при сравнении последних версий Linux и Windows.
Детали в основном объясняются, если вы понимаете значение термина "журнальная файловая система". Пример ссылки .
Согласно этой ссылке, наиболее популярные серии файловых систем Linux получили поддержку журналируемых файловых систем несколько позже, чем у Microsoft.
Кроме того, широко распространено мнение, что файловые системы Linux по-прежнему могли бы нормально восстанавливаться с использованием fsck. Проблема в том, что fsckзанимает так много времени на больших дисках, поэтому ведение журнала является скорее оптимизацией.
Учитывая, сколько времени это может занять на современных больших дисках, трудно спорить о том, что журналирование является более «отказоустойчивым» :-). В принципе, возможно, синхронизация также имеет какое-то значение, независимо от журналируемых файловых систем. Это позволяет вам инициировать немедленную обратную запись, которая включает любое несинхронизированное содержимое файла.(Затем вы должны наблюдать за светодиодами диска или шумом, чтобы определить, когда обратная запись будет завершена ). Это позволяет избежать, например. приходится ждать dirty_writeback_centisecsв файловых системах ext. Некоторые люди даже настроили свои системы для использования «режима ноутбука» , в котором ленивая обратная запись откладывается на неопределенное время для экономии энергии.
Есть еще одна деталь. Журнальные файловые системы в Linux, как правило, предполагают, что они не работают с отключенным barriers. Влияние барьеров на производительность было уменьшено, так что дистрибутивы Linux перестали отключать барьеры по умолчанию. (Кроме того, отключение барьеров может быть «безопасным» в некоторых обстоятельствах и на некотором оборудовании, но это не относится к обычному оборудованию ПК с 2018 года. Redhat больше не рекомендует отключать барьеры даже на таком оборудовании ). Пример ссылки .
цитаты (некоторое форматирование -полезные ссылки -утеряны):
Журналируемая файловая система
Updating file systems to reflect changes to files and directories usually requires many separate write operations. This makes it possible for an interruption (like a power failure or system crash) between writes to leave data structures in an invalid intermediate state.[1]
For example, deleting a file on a Unix file system involves three steps:[5]
- Removing its directory entry.
- Releasing the inode to the pool of free inodes.
- Returning any blocks used to the pool of free disk blocks.
If a crash occurs after step 1 and before step 2, there will be an orphaned inode and hence a storage leak. On the other hand, if only step 2 is performed first before the crash, the not-yet-deleted file will be marked free and possibly be overwritten by something else.
Detecting and recovering from such inconsistencies normally requires a complete walk of its data structures, for example by a tool such as fsck (the file system checker).[2] This must typically be done before the file system is next mounted for read-write access. If the file system is large and if there is relatively little I/O bandwidth, this can take a long time and result in longer downtimes if it blocks the rest of the system from coming back online.
To prevent this, a journaled file system allocates a special area—the journal—in which it records the changes it will make ahead of time. After a crash, recovery simply involves reading the journal from the file system and replaying changes from this journal until the file system is consistent again. The changes are thus said to be atomic (not divisible) in that they either succeed (succeeded originally or are replayed completely during recovery), or are not replayed at all (are skipped because they had not yet been completely written to the journal before the crash occurred).
барьеры
To mitigate the risk of data corruption during power loss, some storage devices use battery-backed write caches. Generally, high-end arrays and some hardware controllers use battery-backed write caches. However, because the cache's volatility is not visible to the kernel, Red Hat Enterprise Linux 6 enables write barriers by default on all supported journaling file systems.
For devices with non-volatile, battery-backed write caches and those with write-caching disabled, you can safely disable write barriers at mount time using the -o nobarrier option for mount. However, some devices do not support write barriers; such devices will log an error message to /var/log/messages (refer to Table 22.1, “Write barrier error messages per file system”).
[...]
Note
The use of nobarrier is no longer recommended in Red Hat Enterprise Linux 6 as the negative performance impact of write barriers is negligible (approximately 3%). The benefits of write barriers typically outweigh the performance benefits of disabling them. Additionally, the nobarrier option should never be used on storage configured on virtual machines.