Pode ext4 fs ser completamente irrecuperável quebrado devido a perda de energia enquanto o disco está escrevendo?

Question

Suponha que você esteja gravando a uma velocidade máxima em disco em um PC com disco ssd ou mecânico (sistema operacional também no mesmo disco, não há bateria / UPS):

cat /dev/urandom > omg.txt

Se as perdas de energia ocorrerem repentinamente durante o processo ou qualquer outro tipo de desligamento / reinicialização inadequada.

O arquivo será corrompido e incapaz de corrigir (ou seja, nenhum dado pode ser recuperado?), haverá uma chance de o sistema de arquivos ser completamente incapaz de inicializar?

    

Answer 1

Will the file be corrupted and unable to fix (i.e. none of any data can be recovered?)

Potencialmente, sim. Existem duas rotas óbvias pelas quais isso pode acontecer.

O Ext4 é um sistema de arquivos de registro de metadados - ele registra apenas as mudanças nos metadados do arquivo (tamanho, localização, datas) - não o conteúdo do arquivo (btrfs e zfs fazem o registro de dados completo com um grande custo de desempenho). Portanto, embora você nunca precise fsck o disco, não se segue que todas as operações de gravação entre a abertura do arquivo e o fechamento + lavagem dos buffers serão concluídas. Não há controle transacional sobre as gravações nos dados do arquivo.

Uma segunda possibilidade é que o disco possa ser fisicamente danificado por picos de energia. Embora o restante do hardware tenda a isolar o disco rígido, ainda haverá algum vazamento.

will there be a chance the file system be completely unable to boot?

Essa é uma pergunta muito diferente - isso é muito menos provável. Certamente, o primeiro cenário só se aplica se você estiver escrevendo o kernel, o bootloader, o ramdisk etc no momento da interrupção.

Veja também este Q & A em unix.stackexchange

    

Answer 2

Ele não deve danificar seu sistema de arquivos (supondo que você use Ext4 e tenha barreiras ativadas - como é por padrão).

Citação do link :

Barriers on by default

This is an option that improves the integrity of the filesystem at the cost of some performance (you can disable it with "mount -o barrier=0", recommended trying it if you're benchmarking). From this LWN article: "The filesystem code must, before writing the [journaling] commit record, be absolutely sure that all of the transaction's information has made it to the journal. Just doing the writes in the proper order is insufficient; contemporary drives maintain large internal caches and will reorder operations for better performance. So the filesystem must explicitly instruct the disk to get all of the journal data onto the media before writing the commit record; if the commit record gets written first, the journal may be corrupted. The kernel's block I/O subsystem makes this capability available through the use of barriers; in essence, a barrier forbids the writing of any blocks after the barrier until all blocks written before the barrier are committed to the media. By using barriers, filesystems can make sure that their on-disk structures remain consistent at all times."

Mais algumas leituras: link .

    

Answer 3

Não é realmente sobre o sistema de arquivos que você escolhe, é sobre o cache de gravação em seu controlador de disco rígido / RAID.

Se você perder o seu poder, tudo no cache é perdido, geralmente não afetará o seu sistema operacional, mas o arquivo pode estar corrompido, sim.

Se você tiver dados críticos em seu servidor, sempre use o controlador UPS ou RAID com bateria.