A corrupção do sistema de arquivos pós-repentina de perda de energia na partição ext3 de uma unidade SSD é um “comportamento esperado”?

Question

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

Normalmente, tudo bem, já que o diário do ext3 mantém as coisas em ordem, então, diferente da perda ocasional de parte de um arquivo de log, as coisas continuam sendo boas.

No entanto, vimos recentemente várias unidades em que, depois de vários ciclos de energia pesada, a partição ext3 começa a desenvolver problemas estruturais - em particular, executamos o e2fsck na partição ext3 e ele encontra um número de questões como as mostradas na listagem de saída na parte inferior desta questão. Executar o e2fsck até parar de reportar erros (ou reformatar a partição) apaga os problemas.

Minha pergunta é ... quais são as implicações de ver problemas como este 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, pois meu entendimento é que (exceto um bug ou problema de hardware) o recurso de roteamento do ext3 deve evitar esses tipos de erros de integridade do sistema de arquivos. (Nota: Eu entendo que os dados do usuário não são unificados e, portanto, mungados / ausentes / arquivos de usuário truncados podem acontecer; 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 comandos de gravação e isso pode fazer com que o diário ext3 fique confuso. Em particular, ele acredita que, mesmo dado hardware funcionando normalmente e software livre de bugs, o journal ext3 apenas torna menos provável, e não impossível, a corrupção do sistema de arquivos, então 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

    

Answer 1

Vocês dois estão errados (talvez?) ... O ext3 está lidando da melhor forma possível com o armazenamento abrupto de seu armazenamento subjacente.

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

De qualquer forma, o cache é usado para ajudar a unir as gravações e prolongar a vida útil da unidade. Se houver gravações em trânsito, a perda súbita de energia é definitivamente a fonte de sua corrupção. Os SSDs empresariais e industriais verdadeiros têm supercapacitores que mantêm a energia por tempo suficiente para mover dados do cache para o armazenamento não-volátil, da mesma maneira suporta o trabalho em cache do controlador RAID suportado por bateria e em flash .

Se a sua unidade não tiver um supercap, as transações em andamento serão perdidas, portanto, a corrupção do sistema de arquivos. É provável que o ext3 esteja dizendo que tudo está em armazenamento estável, mas isso é apenas uma função do cache.

    

Answer 2

Você está certo e seu colega de trabalho está errado. Exceto que algo está errado, o diário garante que você nunca tenha metadados fs inconsistentes. Você pode verificar com hdparm para ver se o cache de gravação da unidade está ativado. Se for, e você não tiver ativado as barreiras de E / S (desativado por padrão no ext3, ativado 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 de unidade a esvaziar 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 silenciosamente ignora os comandos flush. Isso impede que o jornal faça seu trabalho.