La corruption du système de fichiers après une perte d'alimentation soudaine sur la partition ext3 d'un lecteur SSD est-elle un «comportement attendu»?

Mon entreprise fabrique un périphérique Debian Linux intégré qui démarre à partir d'une partition ext3 sur un disque SSD interne. Parce que l'appareil est une «boîte noire» intégrée, il est généralement arrêté de manière grossière, en coupant simplement l'alimentation de l'appareil via un commutateur externe.

Ceci est normalement correct, car la journalisation d'ext3 maintient les choses en ordre, donc à part la perte occasionnelle d'une partie d'un fichier journal, les choses continuent à avancer correctement.

Cependant, nous avons récemment vu un certain nombre d'unités où, après un certain nombre de cycles d'alimentation, la partition ext3 commence à développer des problèmes structurels - en particulier, nous exécutons e2fsck sur la partition ext3 et il trouve un certain nombre de problèmes comme ceux montré dans la liste de sortie au bas de cette question. L'exécution d'e2fsck jusqu'à ce qu'il cesse de signaler des erreurs (ou de reformater la partition) résout les problèmes.

Ma question est ... quelles sont les implications de voir des problèmes comme celui-ci sur un système ext3 / SSD qui a été soumis à de nombreux arrêts soudains / inattendus?

Mon sentiment est que cela pourrait être le signe d'un problème logiciel ou matériel dans notre système, car je pense que (sauf un bogue ou un problème matériel), la fonction de journalisation d'ext3 est censée empêcher ce genre d'erreurs d'intégrité du système de fichiers. (Remarque: je comprends que les données utilisateur ne sont pas journalisées et que des fichiers utilisateur munis / manquants / tronqués peuvent se produire; je parle spécifiquement ici d'erreurs de métadonnées de système de fichiers comme celles illustrées ci-dessous)

Mon collègue, d'autre part, dit que c'est un comportement connu / attendu car les contrôleurs SSD réordonnent parfois les commandes d'écriture et cela peut perturber le journal ext3. En particulier, il estime que même avec un matériel fonctionnant normalement et des logiciels sans bogues, le journal ext3 ne fait que rendre la corruption du système de fichiers moins probable, pas impossible, donc nous ne devrions pas être surpris de voir des problèmes comme celui-ci de temps en temps.

Lequel d'entre nous a raison?

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
source

Avez-vous tous pensé à passer à ext4 ou ZFS?

— mdpc

J'ai pensé à passer à ext4, au moins ... cela aiderait-il à résoudre ce problème? Est-ce que ZFS serait encore mieux?

— Jeremy Friesner

Aucune des deux options ne réglerait ce problème. Nous utilisons toujours des appareils avec des supercondensateurs dans ZFS, et le cache protégé par batterie ou flash est recommandé pour ext4 dans les applications serveur.

— ewwhite

Réponses:

Vous vous trompez tous les deux (peut-être?) ... ext3 fait face du mieux qu'il peut en supprimant si brutalement son stockage sous-jacent.

Votre SSD a probablement un certain type de cache intégré. Vous ne mentionnez pas la marque / le modèle de SSD utilisé, mais cela ressemble à un SSD de niveau consommateur par rapport à un modèle d' entreprise ou industriel .

Dans les deux cas, le cache est utilisé pour aider à fusionner les écritures et à prolonger la durée de vie du lecteur. S'il y a des écritures en transit, la coupure soudaine de courant est définitivement à l'origine de votre corruption. Les véritables SSD d'entreprise et industriels ont des supercondensateurs qui maintiennent suffisamment d'énergie pour déplacer les données du cache vers le stockage non volatile, de la même manière que les caches de contrôleur RAID avec batterie et flash .

Si votre lecteur n'a pas de supercap, les transactions en vol sont perdues, d'où la corruption du système de fichiers. ext3 se fait probablement dire que tout est sur un stockage stable, mais ce n'est qu'une fonction du cache.

— ewwhite
source

Désolé pour vous et tous ceux qui ont voté pour cela, mais vous vous trompez. La gestion de la perte d'écritures en cours est exactement à quoi sert le journal, et tant que le lecteur signale correctement s'il dispose d'un cache d'écriture et obéit aux commandes pour le vider, le journal garantit que les métadonnées ne seront pas incohérentes. Vous n'avez besoin que d'un cache de supercap ou d'une batterie de secours afin de pouvoir activer le cache d'écriture sans avoir à activer les barrières, ce qui sacrifie certaines performances pour maintenir l'exactitude des données.

— psusi

@psusi Le SSD en cours d'utilisation a probablement un cache explicitement activé ou repose sur un tampon interne quel que soit le paramètre OS_level. Les données dans ce cache sont ce qu'un SSD à supercondensateur protégerait.

— ewwhite

Les données du cache n'ont pas besoin d'être protégées si vous activez les barrières d'E / S. La plupart des lecteurs de type consommateur sont livrés avec la mise en cache d'écriture désactivée par défaut et vous devez l'activer si vous le souhaitez, exactement parce que cela provoque des problèmes de corruption si le système d'exploitation ne fait pas attention.

— psusi

@pusi Old maintenant, mais vous mentionnez ceci:

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.

C'est la chose: en raison des contrôleurs de stockage qui ont tendance à assumer des disques plus anciens, les SSD mentent parfois sur le vidage des données. Vous avez besoin de cette supercap.

— Joel Coel

Vous avez raison et votre collègue a tort. Sauf en cas de problème, le journal s'assure que vous ne disposez jamais de métadonnées fs incohérentes. Vous pouvez vérifier avec hdparmsi le cache d'écriture du lecteur est activé. Si c'est le cas, et que vous n'avez pas activé les barrières d'E / S (désactivées par défaut sur ext3, activées par défaut sur ext4), ce serait la cause du problème.

Les barrières sont nécessaires pour forcer le cache d'écriture de lecteur à vider au bon moment pour maintenir la cohérence, mais certains lecteurs se comportent mal et signalent que leur cache d'écriture est désactivé lorsqu'il ne l'est pas, ou ignorent silencieusement les commandes de vidage. Cela empêche le journal de faire son travail.

— psusi
source

-1 pour la lecture-compréhension ...

— ewwhite

@ewwhite, vous devriez peut-être essayer de lire et d'écrire une réponse utile au lieu de cette insulte enfantine.

— psusi

+1 cette réponse pourrait probablement être améliorée, comme toute autre réponse dans n'importe quel QA. Mais fournit au moins quelques éclairages et astuces. @downvoters: améliorez vous-même la réponse, ou commentez les flux possibles, mais le fait de voter contre cette réponse sans justification appropriée est tout simplement dégoûtant!

— Alberto