A corrupção do sistema de arquivos após perda repentina de energia na partição ext3 de uma unidade SSD é "comportamento esperado"?

Minha empresa fabrica um dispositivo Debian Linux incorporado que inicializa a partir de uma partição ext3 em uma unidade SSD interna. Como o dispositivo é uma "caixa preta" incorporada, geralmente é desligada de maneira rude, simplesmente cortando a energia do dispositivo por meio de um comutador externo.

Isso normalmente é bom, já que o diário do ext3 mantém as coisas em ordem; portanto, além da perda ocasional de parte de um arquivo de log, as coisas continuam funcionando bem.

No entanto, recentemente vimos várias unidades em que, após vários ciclos de hard-power, a partição ext3 começa a desenvolver problemas estruturais - em particular, rodamos o e2fsck na partição ext3 e encontramos vários problemas como aqueles mostrado na lista de saída na parte inferior desta pergunta. A execução do e2fsck até que ele pare de relatar erros (ou reformatar a partição) limpa os problemas.

Minha pergunta é ... quais são as implicações de ver problemas como esse em um sistema ext3 / SSD que foi submetido a muitos desligamentos repentinos / inesperados?

Meu sentimento é que isso pode ser um sinal de um problema de software ou hardware em nosso sistema, já que meu entendimento é que (com exceção de um bug ou problema de hardware), o recurso de diário do ext3 deve impedir esse tipo de erro de integridade do sistema de arquivos. (Nota: entendo que os dados do usuário não são mantidos em diário e, portanto, podem ocorrer arquivos de usuário munged / ausentes / truncados; estou falando aqui especificamente sobre erros de metadados do sistema de arquivos, como os mostrados abaixo)

Meu colega de trabalho, por outro lado, diz que esse é um comportamento conhecido / esperado, porque os controladores SSD às vezes reordenam os comandos de gravação e podem causar confusão no diário ext3. Em particular, ele acredita que, mesmo considerando o hardware normalmente funcionando e o software livre de erros, o diário ext3 apenas torna a corrupção do sistema de arquivos menos provável, não impossível, por isso não devemos nos surpreender ao ver problemas como esse de tempos em tempos.

Qual de nós está certo?

Embedded-PC-failsafe:~# ls
Embedded-PC-failsafe:~# umount /mnt/unionfs
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Invalid inode number for '.' in directory inode 46948.
Fix<y>? yes

Directory inode 46948, block 0, offset 12: directory corrupted
Salvage<y>? yes

Entry 'status_2012-11-26_14h13m41.csv' in /var/log/status_logs (46956) has deleted/unused inode 47075.  Clear<y>? yes
Entry 'status_2012-11-26_10h42m58.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47076.  Clear<y>? yes
Entry 'status_2012-11-26_11h29m41.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47080.  Clear<y>? yes
Entry 'status_2012-11-26_11h42m13.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47081.  Clear<y>? yes
Entry 'status_2012-11-26_12h07m17.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47083.  Clear<y>? yes
Entry 'status_2012-11-26_12h14m53.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47085.  Clear<y>? yes
Entry 'status_2012-11-26_15h06m49.csv' in /var/log/status_logs (46956) has deleted/unused inode 47088.  Clear<y>? yes
Entry 'status_2012-11-20_14h50m09.csv' in /var/log/status_logs (46956) has deleted/unused inode 47073.  Clear<y>? yes
Entry 'status_2012-11-20_14h55m32.csv' in /var/log/status_logs (46956) has deleted/unused inode 47074.  Clear<y>? yes
Entry 'status_2012-11-26_11h04m36.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47078.  Clear<y>? yes
Entry 'status_2012-11-26_11h54m45.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47082.  Clear<y>? yes
Entry 'status_2012-11-26_12h12m20.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47084.  Clear<y>? yes
Entry 'status_2012-11-26_12h33m52.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47086.  Clear<y>? yes
Entry 'status_2012-11-26_10h51m59.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47077.  Clear<y>? yes
Entry 'status_2012-11-26_11h17m09.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47079.  Clear<y>? yes
Entry 'status_2012-11-26_12h54m11.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47087.  Clear<y>? yes

Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Couldn't fix parent of inode 46948: Couldn't find parent directory entry

Pass 4: Checking reference counts
Unattached inode 46945
Connect to /lost+found<y>? yes

Inode 46945 ref count is 2, should be 1.  Fix<y>? yes
Inode 46953 ref count is 5, should be 4.  Fix<y>? yes

Pass 5: Checking group summary information
Block bitmap differences:  -(208264--208266) -(210062--210068) -(211343--211491) -(213241--213250) -(213344--213393) -213397 -(213457--213463) -(213516--213521) -(213628--213655) -(213683--213688) -(213709--213728) -(215265--215300) -(215346--215365) -(221541--221551) -(221696--221704) -227517
Fix<y>? yes

Free blocks count wrong for group #6 (17247, counted=17611).
Fix<y>? yes

Free blocks count wrong (161691, counted=162055).
Fix<y>? yes

Inode bitmap differences:  +(47089--47090) +47093 +47095 +(47097--47099) +(47101--47104) -(47219--47220) -47222 -47224 -47228 -47231 -(47347--47348) -47350 -47352 -47356 -47359 -(47457--47488) -47985 -47996 -(47999--48000) -48017 -(48027--48028) -(48030--48032) -48049 -(48059--48060) -(48062--48064) -48081 -(48091--48092) -(48094--48096)
Fix<y>? yes

Free inodes count wrong for group #6 (7608, counted=7624).
Fix<y>? yes

Free inodes count wrong (61919, counted=61935).
Fix<y>? yes


embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****

embeddedrootwrite: ********** WARNING: Filesystem still has errors **********

embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks

Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory entry for '.' in ... (46948) is big.
Split<y>? yes

Missing '..' in directory inode 46948.
Fix<y>? yes

Setting filetype for entry '..' in ... (46948) to 2.
Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Pass 4: Checking reference counts
Inode 2 ref count is 12, should be 13.  Fix<y>? yes

Pass 5: Checking group summary information

embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****
embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks
Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite: clean, 657/62592 files, 87882/249937 blocks

— Jeremy Friesner
fonte

Você já pensou em mudar para ext4 ou ZFS?

— Mdpc

Eu pensei em mudar para ext4, pelo menos ... isso ajudaria a resolver esse problema? O ZFS seria melhor ainda?

— Jeremy Friesner 4/12/12

Nenhuma opção consertaria isso. Ainda usamos dispositivos com supercapacitores no ZFS, e o cache protegido por bateria ou flash é recomendado para ext4 em aplicativos de servidor.

— ewwhite

Respostas:

Vocês dois estão errados (talvez?) ... o ext3 está lidando da melhor maneira possível com a remoção do armazenamento subjacente de forma tão abrupta.

Seu SSD provavelmente possui algum tipo de cache integrado. Você não menciona a marca / modelo do SSD em uso, mas isso soa como um SSD no nível do consumidor versus um modelo corporativo ou industrial .

De qualquer forma, o cache é usado para ajudar a combinar gravações e prolongar a vida útil da unidade. Se houver gravações em trânsito, a perda repentina de energia é definitivamente a fonte de sua corrupção. Os verdadeiros SSDs corporativos e industriais têm supercapacitores que mantêm energia por tempo suficiente para mover dados do cache para o armazenamento não volátil, da mesma forma que os caches do controlador RAID com bateria e flash funcionam .

Se a sua unidade não tiver supercap, as transações em andamento estão sendo perdidas, daí a corrupção do sistema de arquivos. Provavelmente, o ext3 está dizendo que tudo está armazenado de maneira estável, mas isso é apenas uma função do cache.

— ewwhite
fonte

Desculpe a você e a todos que votaram nisso, mas você está errado. O tratamento da perda de gravações em andamento é exatamente para o que o diário se destina e, desde que a unidade relate corretamente se possui um cache de gravação e obedeça aos comandos para liberá-lo, o diário garante que os metadados não serão inconsistentes. Você só precisa de um cache de supercap ou raid suportado por bateria, para poder ativar o cache de gravação sem precisar ativar barreiras, o que sacrifica algum desempenho para manter a correção dos dados.

— Psusi

@psusi O SSD em uso provavelmente tem o cache ativado explicitamente ou depende de um buffer interno, independentemente da configuração do OS_level. Os dados nesse cache são o que um SSD habilitado para supercapacitor protegeria.

— ewwhite

Os dados no cache não precisam de proteção se você ativar as barreiras de IO. A maioria das unidades de tipo consumidor é fornecida com o cache de gravação desativado por padrão e você deve habilitá-lo se desejar, exatamente porque causa problemas de corrupção se o sistema operacional não for cuidadoso.

— Pssi

@pusi Agora, mas você menciona isso:

as long as the drive correctly reports whether it has a write cache and obeys commands to flush it, the journal guarantees that the metadata will not be inconsistent.

é o seguinte: por causa dos controladores de armazenamento que tendem a assumir discos mais antigos, os SSDs às vezes mentem sobre se os dados são liberados. Você precisa dessa super capa.

— Joel Coel

Você está certo e seu colega de trabalho está errado. Com exceção de algo errado, o diário garante que você nunca tenha metadados inconsistentes do fs. Você pode verificar hdparmse o cache de gravação da unidade está ativado. Se estiver, e você não ativou as barreiras de E / S (desativada por padrão no ext3, ativada por padrão no ext4), essa seria a causa do problema.

As barreiras são necessárias para forçar o cache de gravação da unidade a liberar no momento correto para manter a consistência, mas algumas unidades são mal comportadas e relatam que seu cache de gravação está desativado quando não está, ou ignoram silenciosamente os comandos de liberação. Isso impede que o diário faça seu trabalho.

— psusi
fonte

-1 para compreensão de leitura ...

— ewwhite 5/12/12

@whwhite, talvez você deva tentar ler e escrever uma resposta útil em vez desse insulto infantil.

— Psusi

+1 nessa resposta provavelmente poderia ser melhorada, como qualquer outra resposta em qualquer controle de qualidade. Mas pelo menos fornece alguma luz e dicas. @ downvoters: melhore a resposta você mesmo, ou comente sobre possíveis fluxos, mas diminuir o voto dessa resposta sem justificativa adequada é nojento!

— Alberto