If Linux stops responding one might be forced to make an unclean shutdown and in this case one might unknowingly just turn off the power. I read that you should try and make a soft reset with ctrl+prntSc + R +E +I + S+ U+ B with Linux if possible, because a suddently turning off the power might corrupt the file system. What are the details of this and is it true to say that Linux is less resilient that MS-Windows in this case?
I don't think
Ctrl+PrtScr will do much, what you need is
SysRq (usually on the same physical key as
PrtScr, accessed by holding
Alt when pressing that key, for that reason it's a little unclear to be if the "magic" combinations are actually
B function will boot the system, so your combination is a waste of time, only the
B will ever be done, and just booting is about as bad as powercycling.
What can (sometimes) be gained by
SysRq+R,E,I,S,U,B (to me
+ indicates that you need to press all the keys at once, and pressing eight keys at once is hard and not what you want to do - and note that "BUSIER" is actually the classic combination completely backwards), is a nicer shutdown where as much data as possible is written to the disk(s) nicely, so a fsck is not needed on the next boot, and the risk of data loss is minimised.
There's a lot of information, including a complete list of SysRq-combinations and some mnemonics on the wikipedia page for 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?
It might have been useful to make the comparison at one point. That comparison probably explains why these SysRQ commands are quite so well known. However it does not apply in comparing recent Linux and Windows versions.
The details are largely explained if you understand the meaning of "journalling filesystem". Example reference.
As per this reference, the most popular Linux filesystem series gained journalling filesystem support somewhat later than Microsoft's.
Additionally, the popular understanding is that Linux filesystems would still have been able to recover just fine using
fsck, the problem is that
fsck takes so long on larger disks, so journalling is more of an optimization.
Given just how long this can take on modern large disks, it is hard to quibble about journalling being more "resilient" :-). In principle, it's possible the sync also has some use, regardless of journalling filesystems. It lets you trigger an immediate writeback which includes any unsynced file contents. (You must then watch the disk LEDs or noise to guess when writeback has finished). This avoids e.g. having to wait for
dirty_writeback_centisecs on ext filesystems. Some people have even configured their systems to use "laptop mode" where lazy writeback is delayed indefinitely to save power.
There is an additional detail. Journalling filesystems on Linux tend to assume they are not run with
barriers disabled. The performance effect of barriers has been mitigated such that Linux distributions have stopped disabling barriers by default. (Alternatively, disabling barriers could be "safe" in some circumstances and on some hardware, but this does not apply to normal PC hardware as of 2018. Redhat have stopped recommending disabling barriers even on such hardware). Example reference.
quotes (some formatting - useful links - have been lost):
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.
For example, deleting a file on a Unix file system involves three steps:
- 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). 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”).
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.