Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.os.linux.sys > #39397 > unrolled thread

raid 5 e fantasmi

Back to article view | Back to it.comp.os.linux.sys

Contents

  raid 5 e fantasmi Dottor Mistero <occhettuvoi@invalid.org> - 2015-09-25 17:06 +0200
    Re: raid 5 e fantasmi enoquick <enoquick@gmail.com> - 2015-09-25 10:13 -0500
    Re: raid 5 e fantasmi Max_Adamo <maxadamo@usenet.cnntp.org> - 2015-09-25 18:20 +0000
      Re: raid 5 e fantasmi Dottor Mistero <occhettuvoi@invalid.org> - 2015-09-26 09:41 +0200
        Re: raid 5 e fantasmi Piergiorgio Sartor <piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de> - 2015-09-26 09:51 +0200
          Re: raid 5 e fantasmi Dottor Mistero <occhettuvoi@invalid.org> - 2015-09-26 12:15 +0200
        Re: raid 5 e fantasmi Max_Adamo <maxadamo@usenet.cnntp.org> - 2015-09-26 08:11 +0000

#39397 — raid 5 e fantasmi

ciao a tutti,

scrivo qui perchè mi sa che ci vuole uno... bravo :)

Ho una debian wheezy installata su intel core duo che gira stabilmente a
3.5GHz.

La mainboard Asus tiene sei dischi sata2 da 1TB gestiti in raid 5 con
mdadm, il boot è su un altro disco.

Uso la macchina come NAS (samba, ftp, nfs). Se subito dopo il boot provo
a copiare files via samba da un client windows, dopo un rallentamento
iniziale di circa 10 sec. comincio a trasferire alla velocità normale di
una porta gigabit.

Ma il log si riempie di errori come questo (il disco non è sempre lo stesso)
Sep 25 16:34:26 TeraStation kernel: [  119.593274] ata5.00: status: { DRDY }
Sep 25 16:34:26 TeraStation kernel: [  119.593276] ata5.00: failed
command: WRITE FPDMA QUEUED
Sep 25 16:34:26 TeraStation kernel: [  119.593279] ata5.00: cmd
61/00:98:a8:21:7f/04:00:0e:00:00/40 tag 19 ncq 524288 out
Sep 25 16:34:26 TeraStation kernel: [  119.593279]          res
40/00:54:10:cc:80/00:00:0e:00:00/40 Emask 0x50 (ATA bus error)

Chiunque direbbe: disco da cambiare, problemi di alimentazione etc..

Il bello è che, se faccio un reboot per avere una situazione pulita come
prima, creo qualche GB di file sul raid con dd e solo dopo faccio il
file transfer con samba, ottengo avvio della copia immediato e log
pulito, ma nessun errore sul log anche durante l'uso di dd.

E parlo di diverse decine di GB.

A prescindere dai fantasmi che mi fanno dispetti, di che cosa potrebbe
trattarsi? Sui vari forum di debian non ho trovato molto, a parte i
soliti consigli di cambiare l'hw.

saluti spiritici

[toc] | [next] | [standalone]

#39398

Il 25/09/2015 10:06, Dottor Mistero ha scritto:
> ciao a tutti,
>
> scrivo qui perchè mi sa che ci vuole uno... bravo :)
>
> Ho una debian wheezy installata su intel core duo che gira stabilmente a
> 3.5GHz.
>
> La mainboard Asus tiene sei dischi sata2 da 1TB gestiti in raid 5 con
> mdadm, il boot è su un altro disco.
>
> Uso la macchina come NAS (samba, ftp, nfs). Se subito dopo il boot provo
> a copiare files via samba da un client windows, dopo un rallentamento
> iniziale di circa 10 sec. comincio a trasferire alla velocità normale di
> una porta gigabit.
>
> Ma il log si riempie di errori come questo (il disco non è sempre lo stesso)
> Sep 25 16:34:26 TeraStation kernel: [  119.593274] ata5.00: status: { DRDY }
> Sep 25 16:34:26 TeraStation kernel: [  119.593276] ata5.00: failed
> command: WRITE FPDMA QUEUED
> Sep 25 16:34:26 TeraStation kernel: [  119.593279] ata5.00: cmd
> 61/00:98:a8:21:7f/04:00:0e:00:00/40 tag 19 ncq 524288 out
> Sep 25 16:34:26 TeraStation kernel: [  119.593279]          res
> 40/00:54:10:cc:80/00:00:0e:00:00/40 Emask 0x50 (ATA bus error)
>
> Chiunque direbbe: disco da cambiare, problemi di alimentazione etc..
>
> Il bello è che, se faccio un reboot per avere una situazione pulita come
> prima, creo qualche GB di file sul raid con dd e solo dopo faccio il
> file transfer con samba, ottengo avvio della copia immediato e log
> pulito, ma nessun errore sul log anche durante l'uso di dd.
>
> E parlo di diverse decine di GB.
>
> A prescindere dai fantasmi che mi fanno dispetti, di che cosa potrebbe
> trattarsi? Sui vari forum di debian non ho trovato molto, a parte i
> soliti consigli di cambiare l'hw.
>
> saluti spiritici
>


Probabilmente hw difettoso, il controller ad esempio
Che capiti non all' avvio ma dopo un po puo anche essere
Ho gia cambiato una MB per un problema simile

[toc] | [prev] | [next] | [standalone]

#39399

Il Fri, 25 Sep 2015 17:06:03 +0200, Dottor Mistero ha scritto:

> Sep 25 16:34:26 TeraStation kernel: [  119.593274] ata5.00: status: {
> DRDY } Sep 25 16:34:26 TeraStation kernel: [  119.593276] ata5.00:
> failed command: WRITE FPDMA QUEUED Sep 25 16:34:26 TeraStation kernel: [
>  119.593279] ata5.00: cmd 61/00:98:a8:21:7f/04:00:0e:00:00/40 tag 19 ncq
> 524288 out Sep 25 16:34:26 TeraStation kernel: [  119.593279]         
> res 40/00:54:10:cc:80/00:00:0e:00:00/40 Emask 0x50 (ATA bus error)


These errors are usually related to a bad cable or cable connector, or 
possibly bad power. The presence of BadCRC or ICRC is a pretty good 
indicator of a poor quality SATA cable. However, if a better cable does 
not solve the issue, then it is probably a power problem (loose power cable 
or backplane connection, poor connectors, poor power splitter, overloaded 
power supply, too many drives on power rail, bad power supply, etc).


Ovvero:
- un connettore non è perfettamente inserito o è di pessima qualità
- tu hai 6 dischi, ma il tuo alimentatore non ha potenza sufficiente. 

Hai fatto un po' di calcoli sulla potenza dell'alimentatore ed il consumo 
di tutta la roba che hai buttato dentro (cpu, dischi...)?





-- 
Massimiliano Adamo

[toc] | [prev] | [next] | [standalone]

#39404

Il 25/09/15 20:20, Max_Adamo ha scritto:

> Hai fatto un po' di calcoli sulla potenza dell'alimentatore ed il consumo 
> di tutta la roba che hai buttato dentro (cpu, dischi...)?

Controllo le tensioni con sensors e, durante l'uso intensivo dei dischi,
non si nota il minimo calo. Posso non avere riferimenti corretti sul
valore assoluto, ma delle variazioni dovrei accorgermi.

I cavi sono lunghi (50 cm) ma non mi spiego perchè dopo una dd in
scrittura di diversi giga i problemi spariscano anche con samba.

Ho anche pensato alle temperature dei dischi (mai oltre 40 gradi), a
sistema caldo e dopo che sono spariti gli errori faccio un riavvio a
caldo (reboot) provo a scrivere via samba e gli errori si ripresentano,
ancora reboot, stavolta scrivo un file con dd, riprovo samba e gli
errori non ci sono.

Alla peggio cambierò cavi e alimentatore, ma così 'sta cosa non me la
spiego.

saluti misteriosi

[toc] | [prev] | [next] | [standalone]

#39406

On 2015-09-26 09:41, Dottor Mistero wrote:
> Il 25/09/15 20:20, Max_Adamo ha scritto:
> 
>> Hai fatto un po' di calcoli sulla potenza dell'alimentatore ed il consumo 
>> di tutta la roba che hai buttato dentro (cpu, dischi...)?
> 
> Controllo le tensioni con sensors e, durante l'uso intensivo dei dischi,
> non si nota il minimo calo. Posso non avere riferimenti corretti sul
> valore assoluto, ma delle variazioni dovrei accorgermi.

Ma anche no.
Il sensore legge, chesso`, una volta ogni 1~2 secondi i
vari valori.
Se un transitorio e` di 0.2 secondi non lo vedi, ma puo`
essere sufficiente a creare problemi.
In realta`, molto probabilmente non vedi neanche un
transitorio di 1 secondo...

> I cavi sono lunghi (50 cm) ma non mi spiego perchè dopo una dd in
> scrittura di diversi giga i problemi spariscano anche con samba.

Perche` l'HW e` *instabile*.
Dovresti provare con un test che stressi il seek, non il
trasferimento dati.
Di solito, in questa situazione, il consumo aumenta, cosa
che non succede con un semplice "dd".

> Ho anche pensato alle temperature dei dischi (mai oltre 40 gradi), a
> sistema caldo e dopo che sono spariti gli errori faccio un riavvio a
> caldo (reboot) provo a scrivere via samba e gli errori si ripresentano,
> ancora reboot, stavolta scrivo un file con dd, riprovo samba e gli
> errori non ci sono.
> 
> Alla peggio cambierò cavi e alimentatore, ma così 'sta cosa non me la
> spiego.

E` *instabile*, per definizione... :-)

bye,

-- 

piergiorgio

[toc] | [prev] | [next] | [standalone]

#39408

Il 26/09/15 09:51, Piergiorgio Sartor ha scritto:

> E` *instabile*, per definizione... :-)

Si, in effeti era l'hw instabile. Per qualche strana concatenazione di
eventi il problema si presentava in modo curioso, come ho descritto.

Ma aperto il cabinet e scambiati tra loro tutti i cavi, alimentazioni e
sata, il problema è scomparso.

Ovviamente l'hw resta instabile perchè il problema si può ripresentare,
al primo accenno ricompro connettori sata e di alimentazione, e
stavolta... non cinesi. :)

ringraziamenti e saluti

[toc] | [prev] | [next] | [standalone]

#39407

Il Sat, 26 Sep 2015 09:41:20 +0200, Dottor Mistero ha scritto:

> Alla peggio cambierò cavi e alimentatore, ma così 'sta cosa non me la
> spiego.

giusto per confonderti le idee ti invio alcuni link che parlano di 
problemi diversi: 

Anche lui imputava la colpa ai cavi e all'alimentatore ma in questo caso 
si trattava di un problema di firmware: 
https://bbs.archlinux.org/viewtopic.php?id=168530

Qui invece, meglio che leggi tu perché la storia è lunga:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/550559


Quindi: 
- firmware (de che? bios? hai un controller con firmware aggiornabile?)
- driver/kernel
- alimentatore
- cavi
- guasto hardware

hai un bel po' da fare. 

-- 
Massimiliano Adamo

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.os.linux.sys

csiph-web