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
la source
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.
la source
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.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.
la source