Newsgroup: it.comp.os.linux.sys
Titolo: mdadm: patrol read

Ho notato che nei vari server con controller dotate di patrol read, il patrol read mi ha salvato le chiappe più e più volte. (leggasi: la PERC H200 non bisogna *MAI* prenderla in considerazione, tanto non si accorge dei dischi rotti)
 
ora che ho implementato un server con raid sw, dopo anni ed anni che non lo utilizzavo, esiste qualche sistema analogo al patrol read, ovvero che legga tutto il disco e notifichi eventuali errori in I/O ? Serve ad evitare, principalmente, le punture.
 
Vedo che Debian di default, ogni domenica (o ogni prima domenica del mese, non ricordo) effettua un check di consistenza. Su controller DELL il check consistenza ed il patrol read sono due operazioni differenti e complementari.
 
Sul raid sw?
 
la macchina attuale è configurata in RAID-1 a 3 dischi (tutti uguali, tutti della stessa settimana di produzione, vacca boia), c'è il demone che monitora e manda mail (per sicurezza, ho messo in cron lo stesso comando ma in --oneshot, nel caso morisse il demone), ogni domenica c'è il check di consistenza.
 
Altro da fare per stare sicuri e prevenire, per quanto possibile, problematiche ?
 
Sembrano domande da neofita (in effetti lo sono in ambito RAID), ma sono almeno 4-5-6 anni che uso solo RAID hw, con il sw sono rimasto molto indietro.


Uhm, non so cosa faccia patrol read, sulle workstation
che ho gira una volta alla settimana un disk check
di smartmontools e (di notte, un giorno differente) un
RAID check.
 
Se il primo da errori persistenti, di solito cambio il
disco, anche se si tratta di "pending block".
 
Il secondo serve per controllare che non vi siano
problemi latenti con i dischi.
Sulla mailing list lo raccomandano.
 
Un altra cosa che si deve fare, e` settare i timeout
dei dischi (se non gia` cosi`) a 7 secondi (o simile).
Serve ad evitare che un disco (con errori) venga
rimosso dal controller (e quindi dal RAID), senza
che sia necessario.
 
# Set proper error timeout
for i in /sys/class/block/md1/md/rd*
do
  HDD=$( readlink -f ${i}/block | cut -d'/' -f 11 )
  smartctl -l scterc,70,70 /dev/${HDD} || echo 180 >
/sys/class/block/${HDD}/device/timeout
done
 
Oppure:
 
smartctl-timeouts_v1.01.zip
 
Questo secondo sembra alquanto sofisticato, non lo
ho provato personalmente.
 
bye,
 
-- 
 
piergiorgio

 che sia necessario.
 
Se ha errori perchè non lo vuoi rimuovere dal raid ?

 Se ha errori perchè non lo vuoi rimuovere dal raid ?
 
Perche` se vi sono errori latenti su piu` dischi, si
corre il rischio di veder rimossi, per es., 2 dischi
da un RAID-5 con risultati ovvi.
 
Un conto e` avere un disk failure completo, in questo
caso il disco viene rimosso, perche` morto.
Un conto e` un disco che ci mette tempo per leggere
un blocco (perche` rovinato).
In questo caso il sistema (non il RAID), dopo un certo
timeout, considera il disco morto, pur non essendolo.
Quindi il disco verrebbe rimosso, ma se succede su
due (o tre) dischi, solo perche` due (o tre) blocchi
sono difficili da leggere, e` un problema.
Quindi si riduce il timeout, in modo tale che il
disco ritorni un errore di lettura (ma non viene
visto morto) ed il RAID ricostruisce il dato dalla
parita`. Oppure si allunga il timeout del sistema.
La prima soluzione, pero`, consente a tutta la
baracca di funzionare meglio (7 secondi di attesa,
contro 3 minuti).
Da notare che i dischi *RAID* hanno un timeout di
7 secondi ovvero i controller RAID settano il
timeout a 7 secondi (perche` 7, boh?).
 
L'errore, ovviamente, spunta nei log e deve essere
preso in considerazione (forse anche smartmontools
lo riporta in email, non sono sicuro).
 
bye,
 
-- 
 
piergiorgio

 un blocco (perche` rovinato).
 
In teoria il problema che descrivi si presenta solo con dischi desktop non dotati di TLER (quindi non adatti al RAID, per i motivi che hai giustamente citati)
 
Teoricamente, su dischi SAS questa problematica non dovrebbe esistere.

 Se un errore spunta, manda un email...
 
Comunque, mdadm è in grado di rimappare i settori ? Leggevo in giro che le controller raid hw lo fanno, mdadm no.
 
In questo caso, ad esempio, mi ritrovo con smartctl che riporta lo stesso settore danneggiato in ambo i dischi di un RAID-1 hardware. Il come sia possibile che lo stesso settore si danneggi su due dischi non me lo spiego. La controller però non riporta alcuna anomalia. (ma è una PERC H200, mi fido meno di zero)

 che sia necessario.
 
Da me non funziona. Dovrebbe ritornarmi il valore.
https://www.smartmontools.org/wiki/FAQ#WhatiserrorrecoverycontrolERCandwhyitisimportanttoenableitfortheSATAdisksinRAID
 
 
Credo comunque sia un "problema" dei drive sata di fascia consumer.
Averne certezza, però, mi farebbe dormire tranquillo.
 
 
smartctl -l scterc /dev/sda
smartctl 6.4 2014-10-07 r4002 [x86_64-linux-3.16.0-4-amd64] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, 
www.smartmontools.org
 
 
SCSI device successfully opened
 
Use 'smartctl -a' (or '-x') to print SMART (and more) information

 In questo caso, ad esempio, mi ritrovo con smartctl che riporta lo stesso settore danneggiato in ambo i dischi di un RAID-1 hardware. Il come sia possibile che lo stesso settore si danneggi su due dischi non me lo spiego. La controller però non riporta alcuna anomalia. (ma è una PERC H200, mi fido meno di zero)
 
Non saprei proprio...
 
bye,
 
-- 
 
piergiorgio

 Teoricamente, su dischi SAS questa problematica non dovrebbe esistere.
 
Ah! OK, quindi nessun problema.
 
Era solo cautelativo... :-)
 
bye,
 
-- 
 
piergiorgio

 RAID check.
 
Per intenderci, questo è il Patrol Read:
http://www.dell.com/downloads/global/power/ps1q06-20050212-Habas.pdf
 
 
è una feature di LSI, non di DELL, ma il documento DELL lo spiega meglio di quello LSI.
 
C'è qualcosa di simile in mdadm? Il check di mdadm è un semplice 'consistency check' o funge anche da patrol read ?
 
Il patrol sembra un extended test di SMART ma con in aggiunta la rimappatura.
AFAIK, l'extended test legge tutti i settori, ma si ferma al primo non leggibile, non cerca di sistemare nulla. (ma poi, la rimappatura, non dovrebbe farla l'hdd in automatico?)

 AFAIK, l'extended test legge tutti i settori, ma si ferma al primo non leggibile, non cerca di sistemare nulla. (ma poi, la rimappatura, non dovrebbe farla l'hdd in automatico?)
 
Infatti, questo lo dovrebbe far fare il check.
 
Ora, ho scritto dappertutto "dovrebbe", perche`
a volte ha funzionato, a volte no.
Non saprei perche`, forse erano situazioni
diverse (da parte dell'HDD).
 
bye,
 
-- 
 
piergiorgio

 diverse (da parte dell'HDD).
 
e quando non ha funzionato che risultato hai ottenuto?


Niente, il discorso e` questo.
 
Ho avuto HDD con "Pending blocks", questo vuol
dire che l'HDD aspetta per, forse, rilocarli.
Dopo un RAID check, in alcuni casi questi erano
spariti, perche` il RAID, presumo, ha riscritto
il blocco senza problemi, oppure perche` lo ha
letto senza problemi.
In altri casi sono rimasti...
 
Boh, non saprei quale sia stata la differenza,
non ho neanche controllato se erano HDD uguali
o di marche diverse.
 
Devo dire pero`, che una marca di HDD non rilocava
niente, neanche riscrivendo intenzionalmente i
blocchi con "dd".
Rimaneva sempre "Pending".
 
Quindi, forse, e` una questione di HDD.
 
bye,
 
-- 
 
piergiorgio