Come posso individuare la causa della corruzione del filesystem ext3?

Abbiamo un ambiente VMware vSphere 5 in esecuzione di macchine virtuali CentOS 5.8. Nelle ultime due settimane abbiamo avuto cinque incidenti di macchine virtuali aventi un filesystem danneggiato, che richiede che un fsck venga riparato.

Ecco quello che vediamo nei registri:

Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2392098: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 Nov 14 14:39:28 hostname kernel: Aborting journal on device dm-2. Nov 14 14:39:28 hostname kernel: __journal_remove_journal_head: freeing b_committed_data Nov 14 14:39:28 hostname last message repeated 4 times Nov 14 14:39:28 hostname kernel: ext3_abort called. Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): ext3_journal_start_sb: Detected aborted journal Nov 14 14:39:28 hostname kernel: Remounting filesystem read-only Nov 14 14:39:28 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2392099: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 Nov 14 14:31:17 hostname ntpd[3041]: synchronized to 194.238.48.2, stratum 2 Nov 14 15:00:40 hostname kernel: EXT3-fs error (device dm-2): htree_dirblock_to_tree: bad entry in directory #2162743: rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 Nov 14 15:13:17 hostname kernel: __journal_remove_journal_head: freeing b_committed_data 

Il problema sembra accadere mentre rsync'ing i dati dell'applicazione da un altro server. Finora non siamo stati in grado di riprodurre il problema, né individuare una causa fondamentale.

Dopo che abbiamo avuto alcuni server questo problema, abbiamo assunto che ci fosse un problema con il model, quindi abbiamo eliminato tutti i cloni di VM dal model, distrutto il model e creato un nuovo model da zero, installato da un nuovo CentOS scaricato ISO.

Utilizziamo i SAN HP EVA per i datastores e ci siamo trasferiti da un 4400 a un 6300 dopo il primo problema. Dal momento che la mossa e la ricostruzione di nuove macchine virtuali abbiamo visto due volte il problema. Su un VM chiudemmo il server, rimuovamo due CPU virtuali e l'avevamo ripreso, il problema si presentò quasi immediatamente. Sull'altro VM, l'abbiamo riavviato e il problema è accaduto una mezz'ora dopo.

Qualsiasi suggerimento o suggerimento nella direzione giusta sarebbe apprezzato.

  • Problemi con l'aggiunta di host ESXi a vCenter Server
  • VDI deve riavviare il sistema dopo la session
  • Trasferisci una grande quantità di file piccoli
  • Alternative gratuite per vSphere per ESXi (se esiste uno)
  • Aggiornamento di vmware 5.1 e snapshot
  • Imansible aprire il server vCenter collegato
  • Come evitare di scattare fotografie dopo la soglia in VMware ESXi?
  • È ansible eseguire MS SQL Server 2005 sotto VMWare?
  • 2 Solutions collect form web for “Come posso individuare la causa della corruzione del filesystem ext3?”

    C'è un KB riguardante HP EVA, in particolare se si utilizza Round Robin PSP. Innanzitutto è necessario controllare il vmkernel.log per verificare gli errori di archiviazione. Riferimento della voce KB (pdf)

    Per ottimizzare le performance dell'arrays EVA, HP consiglia di modificare il valore IOPS di bilanciamento del carico di rotazione predefinito a 1. Questo aggiornamento deve essere eseguito per each Vdisk utilizzando il seguente command ESX4.x:

     esxcli nmp roundrobin setconfig -t iops -I 1 -d naa.xxxxxxxxx 

    Per ESXi5:

     for i in `esxcli storage nmp device list | grep naa.600` ; do esxcli storage nmp psp roundrobin deviceconfig set -t iops –I 1 -device $i; done 

    Se il problema può essere replicato solo quando si rsyncing i dati da un server a un altro, significa che è correlato a come la consistenza dei dati viene vista dal punto del kernel. Se il kernel pensa che il filesystem sia danneggiato o che abbia qualche danno, si trasformsrà in fs in sola lettura.

    Non so molto su HP EVA, ma ha una cache di scrittura supportta da batteria. Se è così, puoi distriggersre la cache di scrittura su disco e utilizzare la cache di scrittura di arrays SAN. A tal fine, montare con mount -o barriera = 1 e vedere se si vede un miglioramento.

    E ho un istinto che è in qualche modo legato allo stoccaggio, non a qualsiasi errore di fs. Non sono sicuro di come dimostrarlo, ma la maggior parte dei casi che ho visto sulla corruzione di fs in qualche modo e da qualche parte coinvolge lo stoccaggio come il colpevole, se non il principale.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.