Razões para CTRL+PrtScr+R+E+I+S+U+B

Eu não acho que Ctrl+PrtScrvai fazer muito, o que você precisa é SysRq(geralmente na mesma tecla física que PrtScr, acessada segurando Altao pressionar essa tecla, por isso é um pouco incerto se as combinações "mágicas" são realmente SysRq+<letter>ou Alt+SysRq+<letter>).

A Bfunção inicializará o sistema, então sua combinação é uma perda de tempo, apenas o Bserá feito, e apenas inicializar é tão ruim quanto reiniciar.

O que (às vezes) pode ser ganho por SysRq+R,E,I,S,U,B(para mim +indica que você precisa pressionar todas as teclas de uma vez, e pressionar oito teclas de uma vez é difícil e não é o que você deseja fazer - e observe que "BUSIER" é na verdade a combinação clássica completamente para trás), é um desligamento melhor, onde o máximo de dados possível é gravado no(s) disco(s) bem, portanto, um fsck não é necessário na próxima inicialização e o risco de perda de dados é minimizado.

Há muitas informações, incluindo uma lista completa de combinações de SysRq e alguns mnemônicos na página da wikipedia para Magic SysRq .

Quais são os detalhes disso e é verdade que o Linux é menos resiliente que o MS-Windows neste caso?

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 conhecidos. No entanto, 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 "sistema de arquivos com registro em diário". Referência de exemplo .

De acordo com esta referência, a série de sistemas de arquivos Linux mais popular ganhou suporte ao sistema de arquivos journalling um pouco mais tarde do que o da Microsoft.

Além disso, o entendimento popular é que os sistemas de arquivos do Linux ainda seriam capazes de se recuperar bem usando fsck, o problema é que fsckleva muito tempo em discos maiores, portanto, o registro no diário é mais uma otimização.

Dado o tempo que isso pode levar em discos grandes modernos, é difícil questionar sobre o journalling ser mais "resiliente" :-). Em princípio, é possível que a sincronização também tenha alguma utilidade, independentemente dos sistemas de arquivos com journalling. Ele permite acionar um write-back imediato que inclui qualquer conteúdo de arquivo não sincronizado. (Você deve observar os LEDs do disco ou o ruído para adivinhar quando o write-back foi concluído). Isso evita, por exemplo, ter que esperar dirty_writeback_centisecsem sistemas de arquivos ext. Algumas pessoas até configuraram seus sistemas para usar o "modo laptop", onde o write-back preguiçoso é atrasado indefinidamente para economizar energia.

Há um detalhe adicional. Os sistemas de arquivos Journalling no Linux tendem a assumir que não são executados com barriersdesativado. O efeito de desempenho das barreiras foi mitigado de forma que as distribuições do Linux pararam de desabilitar as barreiras por padrão. (Como alternativa, desabilitar barreiras pode ser "seguro" em algumas circunstâncias e em alguns hardwares, mas isso não se aplica a hardware de PC normal a partir de 2018. A Redhat parou de recomendar desabilitar barreiras mesmo em tal hardware). Referência de exemplo .

citações (algumas formatações - links úteis - foram perdidas):

Sistema de arquivos com registro no diário

A atualização de sistemas de arquivos para refletir alterações em arquivos e diretórios geralmente requer muitas operações de gravação separadas. Isso torna possível que uma interrupção (como uma falha de energia ou travamento do sistema) entre as gravações deixe as estruturas de dados em um estado intermediário inválido.[1]

Por exemplo, excluir um arquivo em um sistema de arquivos Unix envolve três etapas:[5]

1. Removendo sua entrada de diretório.
2. Liberando o inode para o pool de inodes livres.
3. Retornando todos os blocos usados ​​para o pool de blocos de disco livres.

Se ocorrer uma falha após a etapa 1 e antes da etapa 2, haverá um inode órfão e, portanto, um vazamento de armazenamento. Por outro lado, se apenas a etapa 2 for executada antes da falha, o arquivo ainda não excluído será marcado como livre e possivelmente será substituído por outra coisa.

Detectar e recuperar tais inconsistências normalmente requer uma caminhada completa em suas estruturas de dados, por exemplo, por uma ferramenta como fsck (o verificador do sistema de arquivos).[2] Normalmente, isso deve ser feito antes que o sistema de arquivos seja montado para acesso de leitura/gravação. Se o sistema de arquivos for grande e se houver relativamente pouca largura de banda de E/S, isso pode levar muito tempo e resultar em tempos de inatividade mais longos se impedir que o restante do sistema volte a ficar on-line.

Para evitar isso, um sistema de arquivos com diário aloca uma área especial — o diário — na qual registra as alterações que fará com antecedência. Após uma falha, a recuperação envolve simplesmente a leitura do diário do sistema de arquivos e a repetição das alterações desse diário até que o sistema de arquivos esteja consistente novamente. As alterações são consideradas atômicas (não divisíveis) no sentido de que são bem-sucedidas (obtidas originalmente ou são reproduzidas completamente durante a recuperação) ou não são reproduzidas (são ignoradas porque ainda não foram completamente gravadas no diário antes do acidente ocorreu).

barreiras

Para atenuar o risco de corrupção de dados durante a perda de energia, alguns dispositivos de armazenamento usam caches de gravação alimentados por bateria. Geralmente, matrizes de ponta e alguns controladores de hardware usam caches de gravação alimentados por bateria. No entanto, como a volatilidade do cache não é visível para o kernel, o Red Hat Enterprise Linux 6 habilita barreiras de gravação por padrão em todos os sistemas de arquivos com registro em diário suportados.

Para dispositivos com caches de gravação não voláteis e alimentados por bateria e aqueles com cache de gravação desabilitado, você pode desativar com segurança as barreiras de gravação no momento da montagem usando a opção -o nobarrier para montagem. No entanto, alguns dispositivos não suportam barreiras de gravação; tais dispositivos registrarão uma mensagem de erro em /var/log/messages (consulte a Tabela 22.1, “Gravar mensagens de erro de barreira por sistema de arquivo”).

[...]

Observação

O uso de nobarrier não é mais recomendado no Red Hat Enterprise Linux 6, pois o impacto negativo no desempenho das barreiras de gravação é insignificante (aproximadamente 3%). Os benefícios das barreiras de gravação geralmente superam os benefícios de desempenho de desativá-los. Além disso, a opção nobarrier nunca deve ser usada em armazenamento configurado em máquinas virtuais.