Nous avons un groupe de terminaux grand public sur lesquels Linux, un serveur Web local et PostgreSQL sont installés. Nous obtenons des rapports sur le terrain des machines avec des problèmes et après enquête, il semble qu'il y ait eu une panne de courant et maintenant il y a quelque chose qui ne va pas avec le disque.
J'avais supposé que le problème proviendrait simplement de la corruption de la base de données ou de la confusion des fichiers avec des modifications récentes, mais il existe d'autres rapports étranges.
- fichiers avec les mauvaises autorisations
- les fichiers qui sont devenus des répertoires (par exemple,
index.php
est maintenant un répertoire) - répertoires devenus des fichiers
- fichiers avec des données brouillées
Il y a des problèmes avec la base de données corrompue, mais c'est quelque chose à quoi je pouvais m'attendre. Ce qui me surprend le plus, ce sont les problèmes de base du système de fichiers - par exemple, les autorisations ou la modification d'un fichier dans un répertoire. Les problèmes se produisent également dans des fichiers qui n'ont pas changé récemment (par exemple, le code du logiciel et la configuration).
Est-ce "normal" pour la corruption de SSD? À l'origine, nous pensions que cela se produisait sur certains SSD bon marché, mais cela se produit sur une marque de marque (de qualité grand public.)
FWIW, nous ne faisons pas d'autofsck sur un démarrage impur (je ne sais pas pourquoi, je suis nouveau). Nous avons des onduleurs installés dans certains endroits, mais parfois cela ne se fait pas correctement, etc. Le système de fichiers est ext4.
La question: pouvons-nous faire quelque chose pour atténuer le problème au niveau du système?
J'ai trouvé des articles faisant référence à la désactivation du cache matériel ou au montage du lecteur en mode synchronisation, mais je ne sais pas si cela pourrait aider dans ce cas (corruption de métadonnées et modifications non récentes). J'ai également lu une référence sur le montage du système de fichiers en mode lecture seule. Nous ne pouvons pas faire cela parce que nous devons écrire, mais nous pourrions faire une partition en lecture seule pour le code et la configuration si cela pouvait aider.
Voici un exemple de lecteur sudo hdparm -i /dev/sda1
:
Model=KINGSTON RBU-SMS151S364GG, FwRev=S9FM02.5, SerialNo=<deleted>
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=125045424
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-3,4,5,6,7
WriteCache=enabled
. Ceci est un énorme problème. Le cache d'écriture ne doit jamais être activé sur les disques durs dotés d'une base de données. Certains fournisseurs, HP par exemple, empêchent en fait d'activer la mise en cache de l'écriture sur le disque dur pour cette raison.