Newsgroup: it.comp.os.linux.sys
Titolo: mdadm: tutto ok ma disco ko

Non saprei come descrivere meglio il thread.
mdadm mi dice che tutto è ok "UU" in tutti i volumi, ma in realtà, ho qualche problema con il disco, dato che non riesco a fare nemmeno un banale "smartctl -a" senza causare load altissimo sul server e bloccare tutto per 10 minuti buoni.
 
Il syslog logga infiniti errori 
 
Jun 12 19:59:35 x kernel: ata1: handling error/timeout
Jun 12 19:59:35 x kernel: ata1: port reset, p_is 0 is 0 pis 0 cmd c017 tf 7f ss 0 se 0
Jun 12 19:59:35 x kernel: ata1: status=0x50 { DriveReady SeekComplete }
 
 
Presumo che il disco stia per andare in vacca, ma la domanda è:
 
come mai mdadm non si accorge di nulla ?


Magari non ha ancora avuto modo di usare quel disco.
O magari il disco ha comunque risposto.
 
Fagli fare un "check" e vedi cosa succede.
 
bye,
 
-- 
 
piergiorgio

 Fagli fare un "check" e vedi cosa succede.
 
Provo.

 Provo.
 
No, non provo, non servirebbe a nulla, smartctl, che non ha ancora finito da prima, inizia a ritornare dati assurdi anche solo come identificazione del disco (seriale e cose del genere)
 
Lo rimuovo dal raid e domani lo cambio.


  Ritengo sia perché sono errori hardware, e mdadm si occupa solo di
quello che succede a livello di servizio Multiple Devices.  Se, pur con
molto consistente ritardo, i dischi gli rispondono, mdadm non si lamenta.
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 molto consistente ritardo, i dischi gli rispondono, mdadm non si lamenta.
 
Non mi pare una bella premessa, ne indice di affidabilità.
 
Comunque, in questo caso, ho rimosso il disco e reinserito nello stesso slot (con metodo "energico"). La situazione si è sbloccata. Forse c'era un problema di cablaggio, è probabile che in precedenza il disco fosse stato inserito troppo delicatamente :)
 
Lo smartctl ora ritorna dati sensati e il check di mdadm sta procedendo spedito (ieri sera si era piantato tutto)

 Non mi pare una bella premessa, ne indice di affidabilità.
 
Perché?
Mdadm è uno strato software, se il controller dei dischi gli dice tutto ok 
(anche se ci mette 1 minuto invece che qualche millesimo di secondo) lui che 
ci può fare?
 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 

 ci può fare?
 
Non gli dice tutto ok, gli dice che tutto non va, ed il kernel ne è al corrente:
 
ata1: handling error/timeout
ata1: port reset, p_is 0 is 0 pis 0 cmd c017 tf 7f ss 0 se 0
ata1: status=0x50 { DriveReady SeekComplete }
sda: Current: sense key=0x0
    ASC=0x0 ASCQ=0x0
 
 
Se io avessi la certezza che questo errore fosse un "normale" timeout ma che il disco sottostante comunque riesce a scrivere correttamente i dati e quindi mdadm a tenere in sincrono il RAID-1, ci potrebbe anche stare.
Ma come faccio ad averne la certezza ? Cosa sta accadendo al disco? (cosa stava accadendo, un bel togli/metti sembra aver risolto)

 stava accadendo, un bel togli/metti sembra aver risolto)
 
Io lo cambierei lo stesso, la fiducia è una cosa seria


 Io lo cambierei lo stesso, la fiducia è una cosa seria
 
E' nuovo, 40 giorni di vita:
 
# smartctl -a /dev/sda | grep -i power_on
  9 Power_On_Hours          0x0032   251   251   000    Old_age   Always       -       947
 
 
E' il server che è vecchio, molto vecchio. Credo sia più un problema della controller o di un errato inserimento del disco. In questo momento sta facendo un check approfondito tramite smart e parallelamente il check mdadm. Tutto sta andando per il meglio.

 Non mi pare una bella premessa, ne indice di affidabilità.
 
Potrei sbagliare, ma la filosofia di "md" e` quella di
evitare il piu` possibile di togliere un disco da un
array, solo perche` vi sono errori, rendendolo "degraded".
 
Il motivo e` anche semplicemente evitare che due errori
(o piu`) su due dischi (o piu`) mettano a terra un array.
 
Cioe`, se un disco torna un errore, "md" ricostruisce
il dato dai rimanenti elementi del RAID.
 
Credo che solo quando il kernel elimina un disco, cioe`
lo considera morto, allora "md" degrada l'array.
 
Nel tuo caso, il disco _risponde_ con un errore ed "md"
non ha alcun motivo di preoccuparsi, dato che, potrebbe
ritornare dati corretti in altre posizioni.
 
Il caso tipico e` un singolo blocco rovinato, che ritorna
errore, e che *non* deve causare un array degradato.
 
Questo e` il motivo per cui serve "smartd" e "logwatch".
 
bye,
 
-- 
 
piergiorgio

 Questo e` il motivo per cui serve "smartd" e "logwatch".
 
smartd è tutt'altro che affidabile.
ho avuto prova in questi giorni che smartd effettua il test lungo
senza riscontrare problemi mentre la controller raid hardware ha
settato il disco come predicted failure a causa di errori in scrittura (visibili dal log della controller)
 

 settato il disco come predicted failure a causa di errori in scrittura (visibili dal log della controller)
 
Errori che, probabilmente, non sono passati indietro
al sistema.
 
"smartd" controlla i parametri SMART, se questi non
dicono niente di nuovo, non lo dice neanche lui.
 
Tra l'altro, come fa *il* controller a sapere che
vi sono errori in scrittura?
Verifica i dati? C'e` un parametro SMART?
C'e` un altro parametro?
 
bye,
 
-- 
 
piergiorgio

 C'e` un altro parametro?
 
Scusami, intendevo in lettura.
Comunque, almeno LSI, ha il patrol read che è interessante. Legge tutto il disco e se un settore non è leggibile, lo rimappa. se non ci riesce, probabilmente significa che il disco è morto o ha finito i settori riallocabili e marca come failed il disco intero. questo, abbinato al check consistency e al long test di smart, danno una maggiore sicurezza.
 
OT: sai dirmi il significato di "Elements in grown defect list" dell'output di smartctl ? Ho cercato in giro ma non viene spiegato esattamente cosa significa.

 OT: sai dirmi il significato di "Elements in grown defect list" dell'output di smartctl ? Ho cercato in giro ma non viene spiegato esattamente cosa significa.
 
Nope, sorry.
 
Credo sia SAS/SCSI specifico, non lo vedo in SATA.
 
bye,
 
-- 
 
piergiorgio

 Credo sia SAS/SCSI specifico, non lo vedo in SATA.
 
Su sata non c'è, ma su sata c'è un prospetto di questo tipo:
 
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   133   133   054    Pre-fail  Offline      -       100
  3 Spin_Up_Time            0x0007   112   112   024    Pre-fail  Always       -       645 (Average 640)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       61
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   121   121   020    Pre-fail  Offline      -       35
  9 Power_On_Hours          0x0012   093   093   000    Old_age   Always       -       49064
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       61
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       320
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       320
194 Temperature_Celsius     0x0002   150   150   000    Old_age   Always       -       40 (Min/Max 17/49)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0
 
che però non mi è chiaro come interpretare.
Ci sono le colonne VALUE WORST THRESH che presumo indichino il valore peggiore e la soglia.
 
Ma come faccio a sapere seil RAW_VALUE sale o scende ?
Cioè, in altre parole, come interpreto tutta questa sfilza di roba ? C'è uno schema o vado a sentimento ?

 Cioè, in altre parole, come interpreto tutta questa sfilza di roba ? C'è uno schema o vado a sentimento ?
 
Va un po' a sentimento...
 
Se cerchi Backblaze e Google riguardo i parametri SMART,
trovi che 5 sono sufficienti per predire rotture.
Uno in particolare, il 198.
Pare che prima abbiano fatto SMART e poi qualcuno abbia
raccolto le statistiche per vedere cosa sia significativo
e cosa no.
 
Se usi "smartctl -x /dev/sdX" ti da ulteriori informazioni
sul drive e su varie ed eventuali di SMART.
 
bye,
 
-- 
 
piergiorgio

 sul drive e su varie ed eventuali di SMART.
 
Interessante, ma sono un mucchio di informazioni che non comprendo e non saprei nemmeno cosa cercare dentro li.
 
Oltretutto su SAS è differente. Questo poppò di roba come lo interpreteresti ?
Vedo una cosa interessante: l'elenco dei settori riallocati.
I 'rewrite in-place' sono i settori fixati riscrivendo il dato tramite ECC, quindi nulla di preoccupante.
Il reassigned indica un settore riallocato, evidentemente quello precedente era morto.
 
Ma il "Require Write or Reassign Blocks command" mi fa pensare a doverlo riallocare a mano..... qui un po spiega:
http://sg.danny.cz/scsi/smartmontools_scsi.html
 "Background Scan"
 
# smartctl -x /dev/sda -d megaraid,0
smartctl 5.42 2011-10-20 r3458 [i686-linux-2.6.18-128.1.6.el5.xs5.5.0.505.1024xen] (local build)
Copyright (C) 2002-11 by Bruce Allen, 
http://smartmontools.sourceforge.net
 
 
Vendor:               SEAGATE 
Product:              ST3146356SS     
Revision:             HS0F
User Capacity:        146,815,733,760 bytes [146 GB]
Logical block size:   512 bytes
Logical Unit id:      0x5000c500287fea17
Serial number:        3QN4LBTB
Device type:          disk
Transport protocol:   SAS
Local Time is:        Mon Jun 13 23:43:52 2016 CEST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK
 
Current Drive Temperature:     35 C
Drive Trip Temperature:        68 C
Elements in grown defect list: 233
Vendor (Seagate) cache information
  Blocks sent to initiator = 830506422
  Blocks received from initiator = 1797859079
  Blocks read from cache and sent to initiator = 
3103565112
 
  Number of read and write commands whose size <= segment size = 1971029373
  Number of read and write commands whose size > segment size = 0
Vendor (Seagate/Hitachi) factory information
  number of hours powered up = 45159,17
  number of minutes until next internal SMART test = 51
 
Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:   1183701472      131         0  1183701603   1183701603     508342,092           0
write:         0        0         1         1          1     153522,965           0
verify: 140618551       10         0  140618561   140618595      39562,609          34
 
Non-medium error count:      108
 
SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background long   Completed                  16   45158                 - [-   -    -]
 
Long (extended) Self Test duration: 1740 seconds [29,0 minutes]
 
Background scan results log
  Status: waiting until BMS interval timer expires
    Accumulated power on time, hours:minutes 45159:10 [2709550 minutes]
    Number of background scans performed: 134,  scan progress: 0,00%
    Number of background medium scans performed: 134
 
   #  when        lba(hex)    [sk,asc,ascq]    reassign_status
   1 29511:52  0000000000030128  [1,17,3]   Recovered via rewrite in-place
   2 29511:52  000000000003010a  [1,18,1]   Successfully reassigned
   3 29511:52  000000000003010b  [1,17,2]   Successfully reassigned
   4 29511:53  0000000000030101  [1,17,3]   Successfully reassigned
   5 29511:53  0000000000030115  [1,18,1]   Recovered via rewrite in-place
   6 29512:00  0000000000032c13  [1,18,1]   Successfully reassigned
   7 29512:25  0000000000032c2c  [1,17,3]   Recovered via rewrite in-place
   8 29512:40  0000000000032c2c  [1,17,3]   Successfully reassigned
   9 29809:32  00000000000b00b1  [1,17,2]   Successfully reassigned
  10 29809:32  00000000000b00bd  [1,17,2]   Successfully reassigned
  11 29809:32  00000000000b00be  [1,17,2]   Successfully reassigned
  12 29809:33  00000000000b00ec  [1,18,1]   Successfully reassigned
  13 29930:32  00000000000301ef  [1,17,2]   Recovered via rewrite in-place
  14 30298:10  0000000000030098  [1,18,1]   Recovered via rewrite in-place
  15 30513:27  00000000000acee0  [1,17,3]   Successfully reassigned
  16 30513:27  00000000000acee3  [1,18,1]   Successfully reassigned
  17 30513:27  00000000000acf39  [1,17,1]   Successfully reassigned
  18 30513:27  00000000000acf59  [1,17,2]   Successfully reassigned
  19 30513:27  00000000000ad3b2  [1,18,1]   Successfully reassigned
  20 30513:27  00000000000ad3c2  [1,17,3]   Successfully reassigned
  21 30513:27  00000000000ad9a0  [1,18,1]   Successfully reassigned
  22 30513:27  00000000000ae9c0  [1,18,1]   Successfully reassigned
  23 30513:27  00000000000ae9f5  [1,18,1]   Successfully reassigned
  24 30513:27  00000000000af3f7  [1,18,1]   Successfully reassigned
  25 30513:27  00000000000af4e2  [1,17,1]   Successfully reassigned
  26 30513:27  00000000000af987  [1,17,1]   Recovered via rewrite in-place
  27 30513:54  000000000003028f  [1,17,2]   Recovered via rewrite in-place
  28 30513:55  000000000003027d  [1,17,2]   Successfully reassigned
  29 30513:55  0000000000030297  [1,17,1]   Recovered via rewrite in-place
  30 30513:58  0000000000030275  [1,17,1]   Successfully reassigned
  31 30513:58  000000000003026d  [1,17,2]   Successfully reassigned
  32 30533:02  00000000000b001e  [1,17,1]   Recovered via rewrite in-place
  33 30533:02  00000000000b0000  [1,18,1]   Recovered via rewrite in-place
  34 30533:02  00000000000b0025  [1,17,1]   Successfully reassigned
  35 30533:03  00000000000b0026  [1,17,2]   Recovered via rewrite in-place
  36 30533:03  00000000000b002b  [1,17,1]   Recovered via rewrite in-place
  37 30533:03  00000000000b002f  [1,17,3]   Recovered via rewrite in-place
  38 30533:03  00000000000b0047  [1,17,3]   Recovered via rewrite in-place
  39 30540:07  0000000000030298  [1,17,2]   Recovered via rewrite in-place
  40 30613:10  0000000000030002  [1,18,1]   Successfully reassigned
  41 30613:10  0000000000030007  [1,17,3]   Recovered via rewrite in-place
 33024 11088:13  007b010003110081  [7,9e,b0]   Reserved [0x0]
 33025 16895:30  0008010003110081  [f,6b,53]   Reserved [0x0]
 33026 19278:40  0070010003110081  [7,ac,f1]   Reserved [0x0]
 33027 22511:29  0018010003110081  [8,9a,fe]   Reserved [0x0]
 33028 23112:15  0008010003160080  [0,a0,ae]   Require Write or Reassign Blocks command
 33029 29508:24  0008010003110081  [0,3,2]   Reserved [0x0]
 33030 29508:24  0008420003110081  [0,3,2]   Reserved [0x0]
 33031 29508:24  0008430003110081  [0,3,2]   Reserved [0x0]
 33032 29508:24  0008420003110081  [0,3,2]   Reserved [0x0]
 33033 29508:24  0008420003110081  [0,3,2]   Reserved [0x0]
 33034 29508:24  0008430003110081  [0,3,2]   Reserved [0x0]
 33035 29508:24  0008420003160080  [0,3,2]   Reserved [0x0]
 33036 29508:24  0008420003110081  [0,3,2]   Reserved [0x0]
 33037 29508:24  0008430003110081  [0,3,2]   Reserved [0x0]
 33038 29508:25  0008010003160080  [0,3,2]   Reserved [0x0]
 33039 29508:25  0008420003110081  [0,3,2]   Reserved [0x0]
 33040 29508:25  0008420003110081  [0,3,2]   Reserved [0x0]
 33041 29508:25  0008430003110081  [0,3,2]   Reserved [0x0]
 33042 29509:41  0011010003110081  [0,15,0]   Reserved [0x0]
 33043 29510:08  0008010003110081  [0,d,33]   Reserved [0x0]
 33044 29512:00  0008010003110081  [0,3,2c]   Reserved [0x0]
 33045 29512:00  0008430003110081  [0,3,2c]   Reserved [0x0]
 33046 29512:00  0008430003110081  [0,3,2c]   Reserved [0x0]
 33047 30570:31  0008010003110081  [0,3,2]   Reserved [0x0]
 33048 32421:08  0008010003110081  [f,27,d7]   Reserved [0x0]
 33049 34653:42  0010010003110081  [1,2d,e5]   Reserved [0x0]
 33050 35930:50  0008010003110081  [3,83,ba]   Reserved [0x0]
 33051 37023:10  0010010003110081  [8,8a,ff]   Reserved [0x0]
 33052 37150:30  0008010003110081  [8,8b,2f]   Reserved [0x0]
 33053 39728:22  0008010003110081  [5,c0,f9]   Reserved [0x0]
 33054 42113:12  0008010003110081  [2,42,ab]   Reserved [0x0]
 33055 43111:10  0008010003110081  [2,22,23]   Reserved [0x0]
 33056 44520:55  0008010003110081  [7,9c,52]   Reserved [0x0]
 33057 44595:05  002c010003110081  [3,fe,4b]   Reserved [0x0]
Protocol Specific port log page for SAS SSP
relative target port id = 1
  generation code = 0
  number of phys = 1
  phy identifier = 0
    attached device type: end device
    attached reason: unknown
    reason: unknown
    negotiated logical link rate: phy enabled; 3 Gbps
    attached initiator port: ssp=1 stp=1 smp=1
    attached target port: ssp=0 stp=0 smp=0
    SAS address = 0x5000c500287fea15
    attached SAS address = 0x50024e807e894400
    attached phy identifier = 0
    Invalid DWORD count = 4
    Running disparity error count = 4
    Loss of DWORD synchronization = 1
    Phy reset problem = 0
relative target port id = 2
  generation code = 0
  number of phys = 1
  phy identifier = 1
    attached device type: no device attached
    attached reason: unknown
    reason: unknown
    negotiated logical link rate: phy enabled; 1.5 Gbps
    attached initiator port: ssp=0 stp=0 smp=0
    attached target port: ssp=0 stp=0 smp=0
    SAS address = 0x5000c500287fea16
    attached SAS address = 0x0
    attached phy identifier = 0
    Invalid DWORD count = 0
    Running disparity error count = 0
    Loss of DWORD synchronization = 0
    Phy reset problem = 0

 Oltretutto su SAS è differente. Questo poppò di roba come lo interpreteresti ?
 
Uh! Davvero un sacco di roba. Anche interessante.
Non saprei, pero`, non uso SAS, sorry.
 
bye,
 
-- 
 
piergiorgio

 lo considera morto, allora "md" degrada l'array.
 
Giusto per fare 4 risate in compagnia:
 
# cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] [raid5] [multipath] [raid6] [raid10] [faulty] 
md1 : active raid1 sda2[0] sdb2[1]
      7815552 blocks [2/2] [UU]
 
md2 : active raid1 sda3[0] sdb3[1]
      995904 blocks [2/2] [UU]
 
md3 : active raid1 sda5[0] sdb5[1]
      31246272 blocks [2/2] [UU]
 
md4 : active raid1 sda6[0] sdb6[1]
      34178176 blocks [2/2] [UU]
 
md5 : active raid1 sda7[0] sdb7[1]
      3783168 blocks [2/2] [UU]
 
md0 : active raid1 sda1[0] sdb1[1]
      128384 blocks [2/2] [UU]
 
unused devices: <none>
 
 
tutto ok vero?
Direi di si.
Peccato che "sda" è a casa mia sul tavolo della cucina e il server, al momento, ha solo sdb inserito.

 Peccato che "sda" è a casa mia sul tavolo della cucina e il server, al momento, ha solo sdb inserito.
 
Secondo me il tuo controller ha problemi... :-)
 
Voglio dire, ho perso dischi per molto meno,
tipo un cavo che si muove.
Sia il kernel che md si sono accorti della cosa
ed il RAID e` diventato degraded.
 
Se il tuo sistema ritiene che sda sia ancora vivo,
forse dovresti controllare i vari elementi, dal
disco a md.
 
C'e` qualcuno che bara...
 
bye,
 
-- 
 
piergiorgio

 C'e` qualcuno che bara...
 
Il disco, secondo smart, è OK.
L'altro giorno l'ho tolto (e nessuno si è accorto di niente) e reinserito nello stesso slot, i timeout indicati dal kernel sono scomparti, il check smart è andato a buon fine (anche prima di rimuoverlo) e il check mdadm ha terminato con successo.
 
Poi da oggi pomeriggio sono ripresi i timeout che mi fanno salire il load alle stelle.
Ho fatto cambiare porta ad un mio collaboratore. Togli dalla porta zero, metti sulla porta tre. Cambiato nulla, il sistema continua a vederlo come sda (?!? invece che sdc) e i timeout sono ancora li.
 
Vado in farm, tolgo il disco, me lo porto a casa e mdadm è tutt'ora bello allegro.
 
come faccio a riconoscere un problema della controller da uno del disco ?
Qui da casa sto facendo un "badblocks" sul disco. Ci sta mettendo un milione di anni.
 
Quindi i casi sono 4:
 
a) la controller del server non funziona
b) smart non è affidabile (l'avevo già detto vero?)
c) mdadm è fuori come un balcone
d) il kernel, preistorico, è buggato.
 
Può anche darsi sia tutti e 4 insieme eh...

 Può anche darsi sia tutti e 4 insieme eh...
 
Si, e` possibile.
Quello che c'e` da fare sono test mirati a verificare
il funzionamento di ogni componente.
 
Tra l'altro, anche "hdparm" ha dei comandi utili.
 
bye,
 
-- 
 
piergiorgio

 Io lo cambierei lo stesso, la fiducia è una cosa seria
 
Io cambierei anche i cavi e/o il cassetto che lo monta. E non sto scherzando,
il comportamento sembra più da problema di connessione che da disco rotto
 
Enrico

 Peccato che "sda" è a casa mia sul tavolo della cucina e il server, al momento, ha solo sdb inserito.
 
L'unico caso per cui questa cosa mi pare, se non sensata, almeno possibile e
che tu abbia tutti i filesystem smontati o marcati readonly.
 
Fin che non scrive,magari non si accorge che un disco è morto.
 
-- 
  Consolatevi! Sul sito 
http://www.sorryeverybody.com
 migliaia di americani
  chiedono scusa al mondo per la rielezione di Bush.	(da Cacao Elefante)

 qualche miglioramento a SMART.
 
Ed è proprio questo il problema principale.
IMHO, quando si parla di check di "funzionalità" di dischi,
dove magari ci sono anche dati preziosi, meglio essere
pessimisti che ottimisti. Mi darebbe più sicurezza uno smart
che al minimo cavillo dicesse: "Hey, cambiami" piuttosto che
uno che dice che tutto funziona per poi ritrovarmi braghe all'aria.
 
Uno smart ottimista è, nel 99.9% dei casi, non solo inutile, ma persino pericoloso.

 uno che dice che tutto funziona per poi ritrovarmi braghe all'aria.
 
Ma questo sei tu che lo devi interpretare.
Un SMART moderno ti fornisce informazioni,
cosa ne fai sta a te.
 
Per esempio, io cambio il disco non appena
vi e` un pending block, quindi ancora prima
di relocation.
Se, pero`, avviene (relocation) allora non
lo considero piu` pericoloso.
 
Devi tu vedere cosa come ti interessa agire.
 
Un altro esempio. C'e` gente che cambia i
dischi dopo un tot di ore, senza che vi sia
necessariamente altro.
E questo e` il metodo migliore, nel caso il
sistema abbia un carico prevedibile.
 
bye,
 
-- 
 
piergiorgio

 Uno smart ottimista è, nel 99.9% dei casi, non solo inutile, ma persino pericoloso.
 
Tra l'altro, non credo vi sia niente che
sia meglio di SMART per valutare lo stato
di un disco.
 
Lo "scrubbing" del controller fornisce
meno informazioni di SMART ed, anzi,
meno affidabile e piu` pericoloso.
Questo perche` trova solo gli errori
che il disco riporta direttamente, non
quelli che maschera (pending, relocation,
varie ed eventuali).
 
bye,
 
-- 
 
piergiorgio

 varie ed eventuali).
 
Informazioni che a me non interessano, in quanto
comunque leggibili.
 
bada bene, ti parlo di RAID, non di dischi singoli.
In RAID, magari 6, a me interessa che i dati siano tutti
leggibili, perchè in caso di guasto ad uno dei dischi, devo
poter ricostruire il raid senza impattare in badblocks.
 
Lo scrubbing della controller legge tutti i settori di tutti i dischi
e, normalmente, li compara con la/le parità. Se tutto va per il meglio,
il RAID è sicuro e ti permetterà di cambiare i dischi in sicurezza.
 
Poi, ovviamente, bisogna vedere quanti dischi ti si rompono, ma considerato
che io uso solo RAID-6, devono rompersi 3 dischi insieme prima di avere 
perdita di dati. Non dico che sia impossibile ma.....
 
Ciò non toglie che si usa smart anche per verificare quanti settori
danneggiati ci sono sul disco, se cominciano ad essere troppi, si cambia
il disco e via andare, perchè tanto lo scrubbing ti ha dato esito positivo
e sai già che potrai ricostruire in sicurezza.
 
Ciò che è pericoloso è fare affidamento solo sui test smart, che spesso (a me è
capitato) danno tutto ok anche quando il disco ha settori non leggibili e sopratutto smart continua a riportare HEALTH_OK anche con un disco da centinaia di settori danneggiati. In pratica HEALTH_OK secondo me verifica solo lo stato dell'elettronica, ma se l'elettronica non dovesse funzionare, il disco sarebbe morto e non c'è smart che tenga. Come fai ad accedere ad un disco con l'elettronica partita ?

 capitato) danno tutto ok anche quando il disco ha settori non leggibili e sopratutto smart continua a riportare HEALTH_OK anche con un disco da centinaia di settori danneggiati. In pratica HEALTH_OK secondo me verifica solo lo stato dell'elettronica, ma se l'elettronica non dovesse funzionare, il disco sarebbe morto e non c'è smart che tenga. Come fai ad accedere ad un disco con l'elettronica partita ?
 
Tutto va usato, non solo SMART.
 
SMART e` un tool, cosi` come "check", cosi come
"bad blocks log", etc.
 
Solo che SMART e` l'unico tool in grado di fornire
informazione *dettagliate*, *precise* e, sopra tutto,
*specifiche* dello stato del disco.
 
Nessun tool esterno e` in grado di fornire tale
livello di informazioni.
 
Quindi non puoi escluderlo, non devi.
 
Ovviamente, non devi neanche usare solo quello.
 
Come scrivevo sopra, se SMART ti dice OK, non
fidarti, ma se ti dice KO, allora cambia disco,
indipendentemente da tutto il resto.
 
bye,
 
-- 
 
piergiorgio

 indipendentemente da tutto il resto.
 
Il problema è che è fin troppo ottimista.
O, messa in altro modo: dice KO quando lo so anche io che il disco è KO, perchè è già morto.

 O, messa in altro modo: dice KO quando lo so anche io che il disco è KO, perchè è già morto.
 
Questo non e` assolutamente vero.
 
Non so che dischi tu abbia, ma i miei, fino adesso,
tranne uno, si sono sempre dimostrati affidabili
sulle informazioni SMART.
 
Non mi e` mai successo che un disco si sia rotto,
senza che SMART si fosse lamentato prima di *qualcosa*.
 
Anzi, da quando uso SMART, non mi e` mai successo che
un disco sia morto quando in uso.
 
Senza contare che il Power_On_Hours da solo fornisce
informazioni sufficienti per valutare lo stato del disco.
 
bye,
 
-- 
 
piergiorgio

 informazioni sufficienti per valutare lo stato del disco.
 
Dopo quanto li cambi ?


Io non uso quel metodo.
Mi pare di ricordare che, dipende dall'uso,
tra 20.000 e 30.000 ore, per HDD "normali".
Per "enterprise", credo fossero 40.000.
 
Dalla mia esperienza, ho visto che gli HDD
seguono abbastanza bene la curva a vasca
da bagno.
 
Se entro 10.000~15.000 non hanno problemi
(pending block, etc.), allora arrivano
tranquillamente a 35.000 ore o piu`.
 
Inoltre ho notato che i dischi sempre in
funzione durano di piu` di quelli che
vengono accesi e spenti.
 
Quindi anche "Power_Cycle_Count" e` un
parametro da tenere d'occhio.
 
bye,
 
-- 
 
piergiorgio