inode orfani poco dopo il riavvio

4 risposte [Ultimo contenuto]
Ritratto di Ilix
Ilix
(Junior)
Offline
Junior
Iscritto: 25/10/2017
Messaggi: 9

Non so se ho beccato il forum giusto ma mi sembra che "Generale" sia il posto migliore dove chiedere un aiuto.
Ho cercato un po' in giro sia qui che googlando ma non sono riuscito a venire a capo del mio problema e ci sbatto la testa da giorni.

Antefatto
Su un server IBN X3500 con debian jessie uno dei 4 dischi SAS del RAID 5 hardware (fatto con il controller del server) risulta danneggiato. Da quel momento sda1 (una delle partizioni risultanti sul disco raid sda) inizia ad avere problemi con inode orfani.

Ogni tot di scritture (non sono riuscito a capire cosa fa scaturire il problema) debian rileva 5 o 6 inode orfani e va in read only mode. Il sistema operativo rimane su ma molti servizi non potendo più scrivere sul disco si arrestano.

Riavvio il server debian corregge sda1 e riparte. Dopo breve una mezzora si riparte con gli inode orfani e via così.

Se avvio il server con una lubuntu minima in rescue mode, l'fsck.ext4 -y /dev/sda1 va a buon fine. Sembra tutto a posto, riavvio il sistema, debian riparte, tutto fila via liscio (a parte ProFTP che non parte da solo ma devo restartarlo) per mezzora e poi di nuovo vengono trovati sempre quei 5/6 inode orfani e il sistema sda1 viene rimontato in read only mode.

Come esco da questo loop infermale?

Ciao. Ilic

Ritratto di Ilix
Ilix
(Junior)
Offline
Junior
Iscritto: 25/10/2017
Messaggi: 9

# tune2fs -l /dev/sda1
tune2fs 1.42.12 (29-Aug-2014)
Filesystem volume name:
Last mounted on: /
Filesystem UUID: 215d2d4d-b400-476f-a634-7c1ae6644ea8
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 52690944
Block count: 210756864
Reserved block count: 10537843
Free blocks: 189421862
Free inodes: 52234282
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 973
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Mon Sep 19 12:20:00 2016
Last mount time: Fri Dec 22 11:02:54 2017
Last write time: Fri Dec 22 11:02:51 2017
Mount count: 1
Maximum mount count: -1
Last checked: Fri Dec 22 10:57:14 2017
Check interval: 0 ()
Lifetime writes: 1846 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 12320780
Default directory hash: half_md4
Directory Hash Seed: 6200ca7e-aa56-422a-854b-53d23139e269
Journal backup: inode blocks

Ritratto di Ilix
Ilix
(Junior)
Offline
Junior
Iscritto: 25/10/2017
Messaggi: 9

Facciamo un riassunto di come ho risolto:
- ho testato uno ad uno tutti i dischi (il controller SAS non ha rilevato problemi)
- ho tolto a caldo un disco per volta dal RAID e poi l'ho reinserito aspettando che il precedente avesse finito di farsi "ricostruire" ricostruire nel RAID

Questa seconda cosa credo abbia funzionato. La mia ipotesi (confermatemi se sono nel giusto o smentitemi se sbaglio) è il primo disco dell'array avesse mantenuto traccia del malfunzionamento del secondo disco (prima della sostituizione) e se la sia portata dietro ingannando Debian.

In sostanza gli errori non erano realmente presenti ma solo mimati.

Vi terrò aggiornati in caso di novità e stravolgimenti di questa teoria.

Ritratto di homeless
homeless
(Guru)
Offline
Guru
Iscritto: 21/10/2011
Messaggi: 1448

Hai comunque sostituito un disco difettoso?

Ritratto di Ilix
Ilix
(Junior)
Offline
Junior
Iscritto: 25/10/2017
Messaggi: 9

homeless ha scritto:

Hai comunque sostituito un disco difettoso?

Sì, certo. Come detto sono partito dal fatto che il disco 2 era difettoso. Il problema è che dopo la sostituzione di quel disco il problema del sistema operativo in read-only mode e degli inode orfani continuava a verificarsi.

Ora invece non succede più.

Il problema è sparito dopo la ricostruzione dell'array anche sul disco 1 (ho estratto il disco, ho riavviato e poi ho reinserito il disco).