What are the details of this and is it true to say that Linux is less resilient that MS-Windows in this case?
Pode ter sido útil fazer a comparação em um ponto. Essa comparação provavelmente explica por que esses comandos SysRQ são tão bem conhecidos. No entanto, isso não se aplica na comparação de versões recentes do Linux e do Windows.
Os detalhes são amplamente explicados se você entender o significado de "journalling filesystem". Exemplo de referência .
De acordo com essa referência, a série de sistemas de arquivos Linux mais popular ganhou o suporte a sistemas de arquivos um pouco depois da Microsoft.
Além disso, o entendimento popular é que os sistemas de arquivos Linux ainda poderiam se recuperar muito bem usando fsck , o problema é que fsck demora tanto em discos maiores, portanto o journalling é mais uma otimização.
Dado o tempo que isso pode levar em discos grandes e modernos, é difícil discutir sobre tornar-se mais "resiliente" :-). Em princípio, é possível que a sincronização também tenha algum uso, independentemente dos sistemas de arquivos de journalling. Ele permite disparar um writeback imediato que inclui qualquer conteúdo de arquivo não sincronizado. (Você deve então observar os LEDs do disco ou o ruído para adivinhar quando o write-back terminou). Isso evita, e. ter que esperar por dirty_writeback_centisecs em sistemas de arquivos ext. Algumas pessoas já configuraram seus sistemas para usar o "modo laptop" , onde o write-back preguiçoso é atrasado indefinidamente para economizar energia.
Há um detalhe adicional. Revisar sistemas de arquivos no Linux tende a supor que eles não são executados com barriers desativado. O efeito de desempenho das barreiras foi atenuado de tal forma que as distribuições Linux pararam de desativar as barreiras por padrão. (Alternativamente, a desativação de barreiras poderia ser "segura" em algumas circunstâncias e em algum hardware, mas isso não se aplica ao hardware normal de PC a partir de 2018. A Redhat parou de recomendar a desativação de barreiras mesmo em tal hardware). Exemplo de referência .
citações (algumas formatações - links úteis - foram perdidas):
Journalling filesystem
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).
barreiras
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.