Discussion:
proxmox e smartarray b320i
(too old to reply)
Nicola Ferrari (#554252)
2014-01-04 08:58:13 UTC
Permalink
Ho preso dei nuovi proliant 380dl gen8 che hanno a bordo il controller
dischi smartarray b320i. L'installer di pve3.1 non vede il disco, che
faccio?

Pensavo di installare una debian e poi portarla a proxmox
http://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Wheezy

ma se alla fine devo comunque mettere il kernel pve, mi sa che cambia
poco o sbaglio?

Ciao,
N


--
+---------------------+
| Linux User #554252 |
+---------------------+
Marco Agostini
2014-01-04 12:34:03 UTC
Permalink
Il giorno 04/gen/2014 09:58, "Nicola Ferrari (#554252)" <nicolafrr-***@public.gmane.org>
ha scritto:
>
> Ho preso dei nuovi proliant 380dl gen8 che hanno a bordo il controller
dischi smartarray b320i. L'installer di pve3.1 non vede il disco, che
faccio?
>
Dai un'occhiata qui

http://188.165.151.221/threads/16444-HP-DL380-Gen8-proxmox-installation-problem

> Pensavo di installare una debian e poi portarla a proxmox
> http://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Wheezy
>
> ma se alla fine devo comunque mettere il kernel pve, mi sa che cambia
poco o sbaglio?
>
Da provare, ma se esistono i "driver" per debian forse la spunti.

Se usi i dischi locali come storage per le VM, ricordati di lanciare un
pveperf per testare le prestazioni.

L'alternativa è quella di acquistare un controller aggiuntivo.
Nicola Ferrari (#554252)
2014-01-04 13:34:40 UTC
Permalink
Grazie Marco della risposta.
Avevo visto il post.

Visto che da quel che ho capito:
- il b320i e' un fakeraid (controller software)
- per attivare la parte RAID ho dovuto mettere nel bios una licenza
apposita ed è quella che lo tiene attivo (e non mi piace)...

Pensavo che, raid sw per raid sw, a questo punto tolgo tutta la
configurazione del b320i licenza compresa, mi tengo le unità fisiche
(cosi' si vedono, ho provato) e su quelle ci configuro md.
Installo una debian7, partiziono con md/lvm seguendo il layout
"standard" di pve, e poi la faccio diventare proxmox seguendo il wiki.

Provo, vi faccio sapere, e in caso di successo posto il tutto!



--
+---------------------+
| Linux User #554252 |
+---------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Marco Agostini
2014-01-04 22:04:13 UTC
Permalink
Il giorno 04/gen/2014 14:35, "Nicola Ferrari (#554252)" <nicolafrr-***@public.gmane.org>
ha scritto:
>
> Grazie Marco della risposta.
> Avevo visto il post.
>
> Visto che da quel che ho capito:
> - il b320i e' un fakeraid (controller software)

Esatto

> Pensavo che, raid sw per raid sw, a questo punto tolgo tutta la
configurazione del b320i licenza compresa, mi tengo le unità fisiche (cosi'
si vedono, ho provato) e su quelle ci configuro md.
> Installo una debian7, partiziono con md/lvm seguendo il layout "standard"
di pve, e poi la faccio diventare proxmox seguendo il wiki.
>
> Provo, vi faccio sapere, e in caso di successo posto il tutto!
>
Per funzionare funziona, a memoria il buon Ciampa già lo aveva fatto in
passato, ma se devi usare il server come virtualizzatore e vuoi usare i
dischi interni come storage per le VM ti consiglio di acquistare un
controller hw.... di livelli SW il tuo server ne ha già a sufficienza da
gestire.
m***@public.gmane.org
2014-01-05 10:36:31 UTC
Permalink
>
> Pensavo che, raid sw per raid sw, a questo punto tolgo tutta la
> configurazione del b320i licenza compresa, mi tengo le unità fisiche (cosi'
> si vedono, ho provato) e su quelle ci configuro md.
> Installo una debian7, partiziono con md/lvm seguendo il layout "standard"
> di pve, e poi la faccio diventare proxmox seguendo il wiki.
>

Ti confermo che funziona, ma le performance sono pessime, e pveperf ne è la
dimostrazione.
Ti consiglio anch'io di acquistare un altro controller.

Ciao,
Mattia.
Nicola Ferrari (#554252)
2014-01-05 11:01:02 UTC
Permalink
cosi' per ridere faccio una prova, poi vedo!
tra le altre cose... ora i dischi sono inseriti frontalmente negli
appositi bay...
Che succede se compro un altro controller? Si monta la scheda, e "muore"
il controller integrato e i dischi se li prende in carico il nuovo
controller? (un po' come accade quando si mettono le vga esterne?)

Non l'ho mai fatto!
Cosa posso acquistare? Avete consigli?


--
+---------------------+
| Linux User #554252 |
+---------------------+
Marco Ciampa
2014-01-05 14:15:31 UTC
Permalink
On Sun, Jan 05, 2014 at 12:01:02PM +0100, Nicola Ferrari (#554252) wrote:
> cosi' per ridere faccio una prova, poi vedo!
> tra le altre cose... ora i dischi sono inseriti frontalmente negli
> appositi bay...
> Che succede se compro un altro controller? Si monta la scheda, e
> "muore" il controller integrato e i dischi se li prende in carico il
> nuovo controller? (un po' come accade quando si mettono le vga
> esterne?)
>
> Non l'ho mai fatto!
> Cosa posso acquistare? Avete consigli?

Chiama HP. Credo che basti scolleare il cavo che va dal cestello che
controller integrato e collegarlo al controller aggiuntivo.

Controllo ma forse il Galilei avrebbe un controller HP 400i da
"prestarti" (per la scuola no?)

--


Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana
di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci
passi. Per quanto cammini, non la raggiungerò mai. A cosa serve
l'utopia? A questo: serve a camminare." Eduardo Galeano

+--------------------+
| Linux User #78271 |
| FSFE fellow #364 |
+--------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Nicola Ferrari (#554252)
2014-01-05 16:40:00 UTC
Permalink
On 01/05/2014 03:15 PM, Marco Ciampa wrote:
> Chiama HP. Credo che basti scolleare il cavo che va dal cestello che
> controller integrato e collegarlo al controller aggiuntivo.
>
> Controllo ma forse il Galilei avrebbe un controller HP 400i da
> "prestarti" (per la scuola no?)
>

Sì, sì è roba di scuola ma in ogni caso le macchine in questione
sarebbero due, quindi non ti preoccupare... Faccio una prova con MD e
faccio un pve-perf. Un tipo sul forum HP che ha il medesimo problema con
CentOS, ha detto tra l'altro di aver avuto problemi con il driver hpvsa
e di aver preferito comunque l'uso di md anche sotto CentOS, e di esser
passato da 300MB/s con MD e esser passato a 280MB/s. Quindi la perdita
forse non è cosi' significativa, e comunque, considerando che non li uso
come storage "in produzione" mi sembrano valori dignitosi.

http://h30499.www3.hp.com/t5/General/hpvsa-driver-for-RHEL6-4-proliant-dl360e-gen8/td-p/6004587
(vedi ultimo post della pagina)

Martedi' faccio qualche prova!!

Ciao,
N


--
+---------------------+
| Linux User #554252 |
+---------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Marco Ciampa
2014-01-05 18:10:08 UTC
Permalink
On Sun, Jan 05, 2014 at 05:40:00PM +0100, Nicola Ferrari (#554252) wrote:
> On 01/05/2014 03:15 PM, Marco Ciampa wrote:
> >Chiama HP. Credo che basti scolleare il cavo che va dal cestello che
> >controller integrato e collegarlo al controller aggiuntivo.
> >
> >Controllo ma forse il Galilei avrebbe un controller HP 400i da
> >"prestarti" (per la scuola no?)
> >
>
> Sì, sì è roba di scuola ma in ogni caso le macchine in questione
> sarebbero due, quindi non ti preoccupare... Faccio una prova con MD
> e faccio un pve-perf. Un tipo sul forum HP che ha il medesimo
> problema con CentOS, ha detto tra l'altro di aver avuto problemi con
> il driver hpvsa e di aver preferito comunque l'uso di md anche sotto
> CentOS, e di esser passato da 300MB/s con MD e esser passato a
> 280MB/s. Quindi la perdita forse non è cosi' significativa, e
> comunque, considerando che non li uso come storage "in produzione"
> mi sembrano valori dignitosi.
>
> http://h30499.www3.hp.com/t5/General/hpvsa-driver-for-RHEL6-4-proliant-dl360e-gen8/td-p/6004587
> (vedi ultimo post della pagina)
>
> Martedi' faccio qualche prova!!
>
> Ciao,
> N

La mia personale opinione è che le ragioni dell'aumento di performance
sul raid hw in caso di raid1 non sono dovute all'impatto sulla cpu del raid
software, che è pressoché nullo visto che fa una copia su entrambi i
dischi e infatti le misure dell'impatto sulla CPU, molto basso, sembrerebbero
darmi ragione, ma all'assenza di una cache sul controller, soprattutto
in scrittura, tant'è che i controller senza flash o batteria
di backup, avendo la cache in scrittura disabilitata e che
disabilitano _anche_ la cache sui dischi, hanno performance
addirittura inferiori al RAID software.

--


Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana
di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci
passi. Per quanto cammini, non la raggiungerò mai. A cosa serve
l'utopia? A questo: serve a camminare." Eduardo Galeano

+--------------------+
| Linux User #78271 |
| FSFE fellow #364 |
+--------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Nicola Ferrari (#554252)
2014-01-05 19:41:45 UTC
Permalink
>
> La mia personale opinione è che le ragioni dell'aumento di performance
> sul raid hw in caso di raid1 non sono dovute all'impatto sulla cpu del raid
> software, che è pressoché nullo visto che fa una copia su entrambi i
> dischi e infatti le misure dell'impatto sulla CPU, molto basso, sembrerebbero
> darmi ragione, ma all'assenza di una cache sul controller, soprattutto
> in scrittura, tant'è che i controller senza flash o batteria
> di backup, avendo la cache in scrittura disabilitata e che
> disabilitano _anche_ la cache sui dischi, hanno performance
> addirittura inferiori al RAID software
>

Si ci sono anche questi aspetti da vedere...
Infatti voglio fare qualche prova sul campo prima di valutare cosa fare.

Il controller ha batteria tampone (o almeno vedo uno stato batteria:
nella configurazione BIOS). Al momento ho configurato il controller in
modo da usare la cache del controller e tenere quella dei dischi
disabilitata.
E' prevista comunque la possibilità di impostare come voglio.
Quale sarebbe la soluzione migliore?

(Dalle prove che ho fatto posso tenere il controller attivo, non
configurare nessun array RAID ed usarlo in modo AHCI SATA Compatibile...
in questo modo vedo i dischi come unità fisiche, ma la cache, essendo
hardware, forse continua a funzionare...)

Nel frattempo ho provato su VBox il boot con grub2 da raid+lvm ed in
effetti non c'e' alcun problema. In fase di configurazione il sistema
inserisce in grub.cfg tutte le accortezze del caso... Grazie!

L'unica accortezza, direi, installare grub sui MBR di tutti i dischi
fisici! (L'installazione lo mette solo su /dev/sda, pur configurando
bene per il RAID tutto il resto). Sbaglio?

Ciao,
N

--
+---------------------+
| Linux User #554252 |
+---------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Flavio Stanchina
2014-01-08 15:35:00 UTC
Permalink
Nicola Ferrari (#554252) wrote:
> Il controller ha batteria tampone (o almeno vedo uno stato batteria:
> nella configurazione BIOS). Al momento ho configurato il controller in
> modo da usare la cache del controller e tenere quella dei dischi
> disabilitata.

La batteria serve solo per poter abilitare la cache in scrittura senza
rischiare di perdere dati in caso di interruzione della corrente; qui
interessa la cache in sé, non la batteria (vedi sotto), ma evidentemente
la presenza di una batteria indica con certezza la presenza di una cache
(altrimenti la batteria non servirebbe a nulla).

> E' prevista comunque la possibilità di impostare come voglio.
> Quale sarebbe la soluzione migliore?
>
> (Dalle prove che ho fatto posso tenere il controller attivo, non
> configurare nessun array RAID ed usarlo in modo AHCI SATA Compatibile...
> in questo modo vedo i dischi come unità fisiche, ma la cache, essendo
> hardware, forse continua a funzionare...)

Per quanto riguarda le performance di PVE, l'elemento importante è la
cache in scrittura sul controller: se rimane attiva anche configurando i
dischi come volumi separati sei a cavallo, ma verifica con pveperf. Per
inciso, pveperf è uno scriptino abbastanza semplice che puoi copiarti da
un host PVE funzionante ed eseguire anche su una Debian liscia (e
probabilmente anche su molte altre distro).

Sempre per inciso, le performance grezze in lettura/scrittura contano
poco (a meno che tu non stia usando dischi del secolo scorso da pochi
megabyte al secondo!): il parametro importante per un virtualizzatore è
il numero di fsync al secondo, il quale indica a grandi linee quante
operazioni di scrittura il sistema è in grado di sopportare
contemporaneamente. Ed è proprio questo parametro ad essere influenzato
pesantemente dalla cache in scrittura, perché con la cache abilitata (e
protetta da batteria) il controller "dice" al sistema operativo di aver
completato la scrittura non appena il dato è arrivato in cache,
operazione evidentemente molto più rapida della scrittura effettiva su
disco che avverrà in un momento successivo.

...e sempre per inciso, ricordati che il RAID software non è una
configurazione supportata dal team di Proxmox per i server di
produzione, anche se molti (me compreso) la usano senza problemi su
server di test.

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Nicola Ferrari (#554252)
2014-01-08 17:08:39 UTC
Permalink
Grazie Flavio di tutte le dritte sempre preziose.
Non sapevo che pveperf si potesse copiare, di solito su debian utilizzo
hdparm -tT /dev/sdX. Il valori corrispondono a quelli di FSync? Appena
posso vado a vedermi com'è fatto pveperf.

Detto questo, si', sapevo che il raid sw non e' supportato da PVE, c'è
scritto anche nel Wiki. Ma piu' che altro, per curiosità mi interessa
vedere i risultati. Per metterci dentro il naso, come si dice.
Poi, per mettere il sistema in produzione, credo che indipendentemente
da tutto farò prendere dei controller aggiuntivi. Non fosse altro per
avere uno "strato software" in meno da gestire. Oltre che per tutto il
resto.

Ciao,
N


--
+---------------------+
| Linux User #554252 |
+---------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Flavio Stanchina
2014-01-08 18:42:21 UTC
Permalink
Nicola Ferrari (#554252) wrote:
> Non sapevo che pveperf si potesse copiare, di solito su debian utilizzo
> hdparm -tT /dev/sdX. Il valori corrispondono a quelli di FSync? Appena
> posso vado a vedermi com'è fatto pveperf.

No, è proprio questo il punto. hdparm misura solo la velocità grezza di
lettura sequenziale (-T dalla cache, -t direttamente dal disco) che
interessa poco su un virtualizzatore, più che altro perché è stimabile
dalle prestazioni dichiarate dei dischi e del controller; al limite è
utile misurarla una tantum per verificare che non ci siano problemi
hardware. Misurare la velocità di *scrittura* sequenziale sarebbe appena
più interessante perché è più facile imbattersi in prestazioni mediocri
se il sistema non è configurato in modo ottimale, specie se c'è di mezzo
un RAID di qualche tipo, ma non perderci tempo perché quello che
interessa davvero è il numero di operazioni fsync() al secondo.
Intendiamoci, le velocità di lettura/scrittura sequenziale hanno
comunque un'influenza determinante sulle prestazioni di alcune
operazioni, ma in genere non sono il collo di bottiglia su un
virtualizzatore che sta eseguendo più macchine virtuali.

fsync() è una funzione che chiede al sistema operativo di scrivere su
disco tutti i dati che il sistema potrebbe aver bufferizzato in memoria,
in modo da garantire che i dati stessi siano salvi in caso di
interruzione della corrente; vedere
http://linux.die.net/man/2/fsync per dettagli. Nel caso di controller
RAID con cache protetta da batteria, in realtà fsync() termina quando i
dati sono nella cache del controller; la batteria in questo caso serve
proprio per proteggere i dati da un'interruzione della corrente e
poterli scrivere autonomamente quando la corrente viene ripristinata,
cosa che evidentemente la cache del sistema operativo (ossia la memoria
del computer) non può fare.

Un virtualizzatore esegue fsync() in continuazione su decine di file per
scrivere piccole quantità di dati e metadati delle varie macchine
virtuali in esecuzione; se l'hardware del virtualizzatore non è in grado
di fare queste operazioni in modo rapido, le macchine virtuali andranno
a scatti e se, ad esempio, la VM è un server web i client potrebbero
andare in timeout perché l'hardware non sta dietro a decine di piccole
richieste. Oppure, se la VM è un domain controller Windows, i login ogni
tanto falliscono. Oppure, se la macchina è un file server, ci vogliono
parecchi secondi per aprire una cartella.

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
g***@public.gmane.org
2014-01-09 06:54:23 UTC
Permalink
Il 08/01/2014 19:42, Flavio Stanchina ha scritto:
> ===CUT=== Nel caso di controller RAID con cache protetta da batteria,
> in realtà fsync() termina quando i dati sono nella cache del
> controller; la batteria in questo caso serve proprio per proteggere i
> dati da un'interruzione della corrente e poterli scrivere
> autonomamente quando la corrente viene ripristinata, cosa che
> evidentemente la cache del sistema operativo (ossia la memoria del
> computer) non può fare.

Dei controller che conosco la batteria serve a dare sufficiente
autonomia al controller per scrivere sul disco i dati immediatamente
dopo l'interruzione.

bye
gdo


--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-09 07:52:20 UTC
Permalink
Il giorno gio, 09/01/2014 alle 07.54 +0100, gdo-***@public.gmane.org ha scritto:
> Il 08/01/2014 19:42, Flavio Stanchina ha scritto:
> > ===CUT=== Nel caso di controller RAID con cache protetta da
> batteria,
> > in realtà fsync() termina quando i dati sono nella cache del
> > controller; la batteria in questo caso serve proprio per proteggere
> i
> > dati da un'interruzione della corrente e poterli scrivere
> > autonomamente quando la corrente viene ripristinata, cosa che
> > evidentemente la cache del sistema operativo (ossia la memoria del
> > computer) non può fare.
>
> Dei controller che conosco la batteria serve a dare sufficiente
> autonomia al controller per scrivere sul disco i dati immediatamente
> dopo l'interruzione.
>
Proprio così. L'impatto della presenza della batteria sulle prestazioni
in scrittura dipende non dalla batteria in sè, ma dal fatto che tutti i
controller seri disabilitano la cache in scrittura del controller quando
la batteria è assente o non operativa, proprio per preservare i dati in
caso di interruzioni.

Bisogna poi anche tener conto, nelle valutazioni complessive, e specie
quando entra in gioco la virtualizzazione, che le cache in gioco sono
parecchie:

http://www.ilsistemista.net/images/stories/kvm_cache_201112/xkvm_cache.png.pagespeed.ic.bGlMeEJuJl.png

ciao,
rob

> bye
> gdo
>
>
Roberto Resoli
2014-01-09 12:36:03 UTC
Permalink
Il giorno gio, 09/01/2014 alle 08.52 +0100, Roberto Resoli ha scritto:
> Il giorno gio, 09/01/2014 alle 07.54 +0100, gdo-***@public.gmane.org ha scritto:
> > Il 08/01/2014 19:42, Flavio Stanchina ha scritto:
...
> > Dei controller che conosco la batteria serve a dare sufficiente
> > autonomia al controller per scrivere sul disco i dati immediatamente
> > dopo l'interruzione.
> >
> Proprio così.

Proprio così un cavolo; grazie a Flavio della spiegazione.

Avevo sempre dato per scontato che la batteria servisse a tenere in vita
lo storage per il tempo necessario prima dello spegnimento, ma questo è
del tutto irragionevole, in effetti.

rob
Flavio Stanchina
2014-01-09 09:08:53 UTC
Permalink
gdo-***@public.gmane.org wrote:
> Il 08/01/2014 19:42, Flavio Stanchina ha scritto:
>> ===CUT=== Nel caso di controller RAID con cache protetta da batteria,
>> in realtà fsync() termina quando i dati sono nella cache del
>> controller; la batteria in questo caso serve proprio per proteggere i
>> dati da un'interruzione della corrente e poterli scrivere
>> autonomamente quando la corrente viene ripristinata, cosa che
>> evidentemente la cache del sistema operativo (ossia la memoria del
>> computer) non può fare.
>
> Dei controller che conosco la batteria serve a dare sufficiente
> autonomia al controller per scrivere sul disco i dati immediatamente
> dopo l'interruzione.

Ne dubito fortemente per due motivi:
a) la batteria è piccola e non credo che sarebbe in grado di alimentare
in modo affidabile un controller RAID ed una manciata di dischi, specie
dischi ad alte prestazioni tipici di un'installazione RAID, nemmeno per
i pochi istanti necessari a scrivere i dati in cache sui dischi;
b) i dischi non sono alimentati direttamente dal controller.

La documentazione che ho letto (controller HP SmartArray) descrive il
funzionamento della cache a batteria come riportato sopra: mantiene i
dati al sicuro fino al successivo ripristino della corrente. C'è anche
scritto per quanto tempo è garantito che i dati rimangano in cache.

Alcuni controller moderni usano memoria flash invece di RAM + batteria.
Evidentemente la flash non è in grado di alimentare alcunché.

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Marco Ciampa
2014-01-09 11:44:27 UTC
Permalink
On Thu, Jan 09, 2014 at 10:08:53AM +0100, Flavio Stanchina wrote:
> gdo-***@public.gmane.org wrote:
> >Il 08/01/2014 19:42, Flavio Stanchina ha scritto:
> >>===CUT=== Nel caso di controller RAID con cache protetta da batteria,
> >>in realtà fsync() termina quando i dati sono nella cache del
> >>controller; la batteria in questo caso serve proprio per proteggere i
> >>dati da un'interruzione della corrente e poterli scrivere
> >>autonomamente quando la corrente viene ripristinata, cosa che
> >>evidentemente la cache del sistema operativo (ossia la memoria del
> >>computer) non può fare.
> >
> >Dei controller che conosco la batteria serve a dare sufficiente
> >autonomia al controller per scrivere sul disco i dati immediatamente
> >dopo l'interruzione.
>
> Ne dubito fortemente per due motivi:
> a) la batteria è piccola e non credo che sarebbe in grado di
> alimentare in modo affidabile un controller RAID ed una manciata di
> dischi, specie dischi ad alte prestazioni tipici di un'installazione
> RAID, nemmeno per i pochi istanti necessari a scrivere i dati in
> cache sui dischi;
> b) i dischi non sono alimentati direttamente dal controller.
>
> La documentazione che ho letto (controller HP SmartArray) descrive
> il funzionamento della cache a batteria come riportato sopra:
> mantiene i dati al sicuro fino al successivo ripristino della
> corrente. C'è anche scritto per quanto tempo è garantito che i dati
> rimangano in cache.
>
> Alcuni controller moderni usano memoria flash invece di RAM +
> batteria. Evidentemente la flash non è in grado di alimentare
> alcunché.

Confermo. Il funzionamento è come riportato da Flavio.

--


Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana
di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci
passi. Per quanto cammini, non la raggiungerò mai. A cosa serve
l'utopia? A questo: serve a camminare." Eduardo Galeano

+--------------------+
| Linux User #78271 |
| FSFE fellow #364 |
+--------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
g***@public.gmane.org
2014-01-09 11:46:16 UTC
Permalink
Il 09/01/2014 10:08, Flavio Stanchina ha scritto:
> gdo-***@public.gmane.org wrote:
>> Il 08/01/2014 19:42, Flavio Stanchina ha scritto:
>>> ===CUT=== Nel caso di controller RAID con cache protetta da batteria,
>>> in realtà fsync() termina quando i dati sono nella cache del
>>> controller; la batteria in questo caso serve proprio per proteggere i
>>> dati da un'interruzione della corrente e poterli scrivere
>>> autonomamente quando la corrente viene ripristinata, cosa che
>>> evidentemente la cache del sistema operativo (ossia la memoria del
>>> computer) non può fare.
>>
>> Dei controller che conosco la batteria serve a dare sufficiente
>> autonomia al controller per scrivere sul disco i dati immediatamente
>> dopo l'interruzione.
>
> Ne dubito fortemente per due motivi:
> a) la batteria è piccola e non credo che sarebbe in grado di
> alimentare in modo affidabile un controller RAID ed una manciata di
> dischi, specie dischi ad alte prestazioni tipici di un'installazione
> RAID, nemmeno per i pochi istanti necessari a scrivere i dati in cache
> sui dischi;
> b) i dischi non sono alimentati direttamente dal controller.
>

Sì, ho preso un granchio :-) forse indotto dall'uso di UPS che se
monitorati, permettono di gestire uno shutdown corretto anche senza
batteria tampone in caso di caduta dell'alimentazione (ma non di "crash"
del sistema operativo).

Ma la BBU di un controller RAID effetttivamente salvaguardia solo la
cache del controller.
Nella documentazione non ricordo vi fossero indicazioni sulla durata
della batteria, quindi della salvaguardia dei dati in essa conservati.

gdo



--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-14 11:43:02 UTC
Permalink
On Mer, 8 Gennaio 2014 16:35, Flavio Stanchina wrote:
...
> ...e sempre per inciso, ricordati che il RAID software non è una
> configurazione supportata dal team di Proxmox per i server di
> produzione, anche se molti (me compreso) la usano senza problemi su
> server di test.

Per curiosità, quali sono i valori di pveperf che ottieni? Approfondendo
un po' la questione, grazie anche alle tue note, ho visto che il valore di
fsync/sec riportato da pveperf può dipendere anche molto dal tipo di
filesystem su cui viene effettuato ( / di default), e dalle opzioni di
mount.

rob
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Flavio Stanchina
2014-01-14 13:47:22 UTC
Permalink
Roberto Resoli wrote:
> On Mer, 8 Gennaio 2014 16:35, Flavio Stanchina wrote:
> ...
>> ...e sempre per inciso, ricordati che il RAID software non è una
>> configurazione supportata dal team di Proxmox per i server di
>> produzione, anche se molti (me compreso) la usano senza problemi su
>> server di test.
>
> Per curiosità, quali sono i valori di pveperf che ottieni? Approfondendo
> un po' la questione, grazie anche alle tue note, ho visto che il valore di
> fsync/sec riportato da pveperf può dipendere anche molto dal tipo di
> filesystem su cui viene effettuato ( / di default), e dalle opzioni di
> mount.

Esattamente, su un file system dipende da molti piccoli dettagli: ad
esempio, usare le opzioni noatime o relatime può fare una bella
differenza. Usare barrier=1 fa una grossa differenza come immaginerai,
ma usare barrier=0 è cercar rogne (ed è esattamente il motivo per cui
serve la cache in scrittura protetta da batteria).

Se configuri i dischi delle macchine virtuali direttamente su volumi
LVM, non c'è di mezzo un file system da "accordare" e le prestazioni
sono più vicine ai limiti dell'hardware.

Non ho sottomano i risultati precisi delle altre macchine su cui avevo
provato e al momento non ne ho più, eccetto il mio computer a casa che
in questo momento è spento :)
ma l'ordine di grandezza che ci si può aspettare da un RAID senza cache
in scrittura è da poche decine di fsync/secondo a 200-250.

Questo è il risultato di pveperf su un HP Microserver sul quale usavo
anche PVE (ora non più, ma il sistema è rimasto pressoché identico):

# ./bin/pveperf /
CPU BOGOMIPS: 5990.07
REGEX/SECOND: 615750
HD SIZE: 7.87 GB (/dev/mapper/vg0-root)
BUFFERED READS: 99.49 MB/sec
AVERAGE SEEK TIME: 10.69 ms
FSYNCS/SECOND: 53.44
DNS EXT: 255.71 ms

# grep root /proc/mounts
rootfs / rootfs rw 0 0
/dev/mapper/vg0-root / ext4 rw,relatime,errors=remount-ro,\
user_xattr,acl,barrier=1,data=ordered 0 0

La CPU è sfigata ma il sottosistema di I/O è abbastanza buono; anzi
ottimo, se si considera che il server senza RAM e dischi costava circa
250€! I dischi sono Seagate Barracuda SATA da 1TB in RAID 1, i volumi
sono tutti ext4 su LVM. Le prestazioni di lettura/scrittura sono oneste,
nell'ordine dei 100 MB/s in lettura e 50 MB/s abbondanti in scrittura,
ma come vedi i fsync al secondo fanno pena: va bene per virtualizzare
uno o due desktop, o server di test poco carichi, ma un paio di server
mezzi carichi andrebbero da schifo.

In ogni caso era molto stabile con PVE, mai avuto problemi.

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-14 14:37:31 UTC
Permalink
Il giorno mar, 14/01/2014 alle 14.47 +0100, Flavio Stanchina ha scritto:
> Roberto Resoli wrote:
> > On Mer, 8 Gennaio 2014 16:35, Flavio Stanchina wrote:
> > ...
> >> ...e sempre per inciso, ricordati che il RAID software non è una
> >> configurazione supportata dal team di Proxmox per i server di
> >> produzione, anche se molti (me compreso) la usano senza problemi su
> >> server di test.
> >
> > Per curiosità, quali sono i valori di pveperf che ottieni? Approfondendo
> > un po' la questione, grazie anche alle tue note, ho visto che il valore di
> > fsync/sec riportato da pveperf può dipendere anche molto dal tipo di
> > filesystem su cui viene effettuato ( / di default), e dalle opzioni di
> > mount.
>
> Esattamente, su un file system dipende da molti piccoli dettagli: ad
> esempio, usare le opzioni noatime o relatime può fare una bella
> differenza. Usare barrier=1 fa una grossa differenza come immaginerai,
> ma usare barrier=0 è cercar rogne (ed è esattamente il motivo per cui
> serve la cache in scrittura protetta da batteria).

Certo. Difatti proxmox attiva di default tutte queste opzioni, e anche
altre, come data=ordered

# mount | grep pve
/dev/mapper/pve-root on / type ext4
(rw,relatime,errors=remount-ro,barrier=1,stripe=320,data=ordered)
/dev/mapper/pve-data on /var/lib/vz type ext4
(rw,relatime,barrier=1,stripe=320,data=ordered)

Anche il tipo di filesystem può fare grosse differenze:

http://forum.proxmox.com/threads/9347-Software-and-Hardware-RAID-Performance-ext3-ext4-xfs-with-Proxmox

> Se configuri i dischi delle macchine virtuali direttamente su volumi
> LVM, non c'è di mezzo un file system da "accordare" e le prestazioni
> sono più vicine ai limiti dell'hardware.

hai centrato esattamente quello che stavo pensando :-)

> Non ho sottomano i risultati precisi delle altre macchine su cui avevo
> provato e al momento non ne ho più, eccetto il mio computer a casa che
> in questo momento è spento :)

Il motivo della domanda è che ho da poco acceso il mio :-) , e vorrei
capire quanto è giustificata un'eventuale ulteriore spesa per un
controller.
Per ora ho installato su software (md)raid 1, utilizzando più o meno
questa guida per migrare velocemente un'altrettanto veloce installazione
pve 3.1 da iso:

https://labs.truelite.it/projects/truedoc/wiki/ProxmoxOnRaid1

> ma l'ordine di grandezza che ci si può aspettare da un RAID senza cache
> in scrittura è da poche decine di fsync/secondo a 200-250.
>
> Questo è il risultato di pveperf su un HP Microserver sul quale usavo
> anche PVE (ora non più, ma il sistema è rimasto pressoché identico):
>
> # ./bin/pveperf /
> CPU BOGOMIPS: 5990.07
> REGEX/SECOND: 615750
> HD SIZE: 7.87 GB (/dev/mapper/vg0-root)
> BUFFERED READS: 99.49 MB/sec
> AVERAGE SEEK TIME: 10.69 ms
> FSYNCS/SECOND: 53.44
> DNS EXT: 255.71 ms
>
> # grep root /proc/mounts
> rootfs / rootfs rw 0 0
> /dev/mapper/vg0-root / ext4 rw,relatime,errors=remount-ro,\
> user_xattr,acl,barrier=1,data=ordered 0 0

Sono coerenti (gli FSYNCS/SECOND) con quelle che ottengo sulla nuova MB
Avoton, con due dischi in raid1

> La CPU è sfigata ma il sottosistema di I/O è abbastanza buono; anzi
> ottimo, se si considera che il server senza RAM e dischi costava circa
> 250€! I dischi sono Seagate Barracuda SATA da 1TB in RAID 1, i volumi
> sono tutti ext4 su LVM. Le prestazioni di lettura/scrittura sono oneste,
> nell'ordine dei 100 MB/s in lettura e 50 MB/s abbondanti in scrittura,
> ma come vedi i fsync al secondo fanno pena: va bene per virtualizzare
> uno o due desktop, o server di test poco carichi, ma un paio di server
> mezzi carichi andrebbero da schifo.

si, è quello che mi aspetto.

> In ogni caso era molto stabile con PVE, mai avuto problemi.

Grazie mille; appena ho qualche vm installata (ovviamente su storage raw
LVM, a questo punto) riporto ulteriori impressioni.

Ciao,
rob
Flavio Stanchina
2014-01-14 16:32:21 UTC
Permalink
Roberto Resoli wrote:
> Anche il tipo di filesystem può fare grosse differenze:
>
> http://forum.proxmox.com/threads/9347-Software-and-Hardware-RAID-Performance-ext3-ext4-xfs-with-Proxmox

Alcuni numeri non mi convincono, mi sembrano troppo alti per un RAID. Ho
il dubbio che avessero una delle cache in scrittura abilitata (o sui
dischi o sul controller, nonostante l'assenza di batteria... alcuni te
lo lasciano fare) e non se ne fossero accorti.

>> Non ho sottomano i risultati precisi delle altre macchine su cui avevo
>> provato e al momento non ne ho più, eccetto il mio computer a casa che
>> in questo momento è spento :)
>
> Il motivo della domanda è che ho da poco acceso il mio :-) , e vorrei
> capire quanto è giustificata un'eventuale ulteriore spesa per un
> controller.

Mah, se non ci devi far girare VM "always on" e cariche, non credo che
sia giustificato.

> Per ora ho installato su software (md)raid 1, utilizzando più o meno
> questa guida per migrare velocemente un'altrettanto veloce installazione
> pve 3.1 da iso:
>
> https://labs.truelite.it/projects/truedoc/wiki/ProxmoxOnRaid1

Bella guida, precisa e sintetica. Smanettando si riesce a fare senza
dover trasferire due volte i dati, ossia mirrorando le partizioni
esistenti, ma va bene così.

>> ma l'ordine di grandezza che ci si può aspettare da un RAID senza cache
>> in scrittura è da poche decine di fsync/secondo a 200-250.
>>
>> Questo è il risultato di pveperf su un HP Microserver [...]
>> FSYNCS/SECOND: 53.44
>
> Sono coerenti (gli FSYNCS/SECOND) con quelle che ottengo sulla nuova MB
> Avoton, con due dischi in raid1

Per curiosità, questi sono i risultati su un serverino di test senza
RAID, con un disco SATA da 320 GB ormai vecchiotto:

# pveperf /
CPU BOGOMIPS: 10605.30
REGEX/SECOND: 1041884
HD SIZE: 7.87 GB (/dev/mapper/pve-root)
BUFFERED READS: 79.51 MB/sec
AVERAGE SEEK TIME: 8.07 ms
FSYNCS/SECOND: 1101.92
DNS EXT: 261.34 ms
DNS INT: 2002.44 ms

(non guardare il DNS interno, sta cercando di risolvere qualcosa di
sbagliato ma non gli sono corso dietro)

Come vedi le prestazioni sono ben più alte, essendo attiva la cache in
scrittura dell'unico disco. Ma questo server in particolare lo uso più
che altro per fare test di installazione, manutenzione ed upgrade di PVE
stesso, quindi mi interessa assai poco se esplode: le (poche) VM che ho
su sono perlopiù spente e comunque di nessun interesse pratico.

Valutando bene il proprio caso, può valere la pena lasciare alcune VM su
un disco non in RAID: ad es. se hai -- chessò -- un Windows XP per far
girare qualche vecchio programma su cui non installerai mai niente di
nuovo, fai un backup della VM una volta ogni tanto e ti premuri di fare
frequentemente il backup dei dati a livello di file o li tieni su un
server (anche se una macchina così non avrà bisogno di gran prestazioni,
l'interattività è una delle prime cose a soffrire se l'I/O saltella);
oppure se metti su un cluster di server già ridondanti per i fatti loro,
virtualizzi solo per la comodità di sganciarti dal ferro ed hai le
immagini pronte per rimpiazzare i morti.

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-14 22:25:04 UTC
Permalink
Il 14/01/2014 15:37, Roberto Resoli ha scritto:
> Il giorno mar, 14/01/2014 alle 14.47 +0100, Flavio Stanchina ha scritto:
...
> Grazie mille; appena ho qualche vm installata (ovviamente su storage raw
> LVM, a questo punto) riporto ulteriori impressioni.

Velocemente:

Nota Bene: in entrambi i casi ho lasciato ext3
come filesystem.

=== senza raid ===
CPU BOGOMIPS: 38397.20
REGEX/SECOND: 375059
HD SIZE: 19.69 GB (/dev/mapper/pve-root)
BUFFERED READS: 160.93 MB/sec
AVERAGE SEEK TIME: 9.88 ms
FSYNCS/SECOND: 1028.82
DNS EXT: 86.65 ms
DNS INT: 50.10 ms

=== su raid 1 ===
CPU BOGOMIPS: 38397.60
REGEX/SECOND: 366374
HD SIZE: 19.69 GB (/dev/mapper/pve-root)
BUFFERED READS: 159.32 MB/sec
AVERAGE SEEK TIME: 7.95 ms
FSYNCS/SECOND: 727.28
DNS EXT: 116.91 ms
DNS INT: 48.42 ms

Per curiosità, ho copiato pveperf su una vm wheezy che gira
su uno storage lvm basato sempre su mdraid 1 (stessi due dischi)
(basta solo ìnstallare qualche libreria perl per le dipendenze)

N.B:: il filesystem è ext4

CPU BOGOMIPS: 4800.16
REGEX/SECOND: 310008
HD SIZE: 9.39 GB
BUFFERED READS: 155.60 MB/sec
AVERAGE SEEK TIME: 8.09 ms
FSYNCS/SECOND: 52.79
DNS EXT: 81.90 ms
DNS INT: 2.69 ms (lan)

rob

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Marco Agostini
2014-01-15 07:01:39 UTC
Permalink
Il 14 gennaio 2014 23:25, Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha scritto:
>
questo sotto è ext3 con raid1 (lo riporto per chiarezza)

> === su raid 1 ===
> CPU BOGOMIPS: 38397.60
> REGEX/SECOND: 366374
> HD SIZE: 19.69 GB (/dev/mapper/pve-root)
> BUFFERED READS: 159.32 MB/sec
> AVERAGE SEEK TIME: 7.95 ms
> FSYNCS/SECOND: 727.28
> DNS EXT: 116.91 ms
> DNS INT: 48.42 ms
>

questo sotto è ext4 con raid1>

> CPU BOGOMIPS: 4800.16
> REGEX/SECOND: 310008
> HD SIZE: 9.39 GB
> BUFFERED READS: 155.60 MB/sec
> AVERAGE SEEK TIME: 8.09 ms
> FSYNCS/SECOND: 52.79
> DNS EXT: 81.90 ms
> DNS INT: 2.69 ms (lan)
>

posteresti i parametri di mount di entrambe i filesystem ext3 e
ext4.... sembra veramente strano questo abisso di prestazioni.
Roberto Resoli
2014-01-15 09:06:52 UTC
Permalink
Il giorno mer, 15/01/2014 alle 08.01 +0100, Marco Agostini ha scritto:
> Il 14 gennaio 2014 23:25, Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha scritto:
> >
> questo sotto è ext3 con raid1 (lo riporto per chiarezza)
>
> > === su raid 1 ===
> > CPU BOGOMIPS: 38397.60
> > REGEX/SECOND: 366374
> > HD SIZE: 19.69 GB (/dev/mapper/pve-root)
> > BUFFERED READS: 159.32 MB/sec
> > AVERAGE SEEK TIME: 7.95 ms
> > FSYNCS/SECOND: 727.28
> > DNS EXT: 116.91 ms
> > DNS INT: 48.42 ms
> >
>
> questo sotto è ext4 con raid1>
>
> > CPU BOGOMIPS: 4800.16
> > REGEX/SECOND: 310008
> > HD SIZE: 9.39 GB
> > BUFFERED READS: 155.60 MB/sec
> > AVERAGE SEEK TIME: 8.09 ms
> > FSYNCS/SECOND: 52.79
> > DNS EXT: 81.90 ms
> > DNS INT: 2.69 ms (lan)
> >
>
> posteresti i parametri di mount di entrambe i filesystem ext3 e
> ext4.... sembra veramente strano questo abisso di prestazioni.

Esatto, infatti:

# mount | grep 'ext3\|ext4'

/dev/mapper/pve-root on / type ext3
(rw,relatime,errors=remount-ro,user_xattr,acl,barrier=0,data=ordered)


/dev/mapper/img1-vm--100--disk--1p1 on /tmp/100 type ext4
(rw,relatime,barrier=1,data=ordered)


quindi le barriers abilitate sembrano fare la differenza.
Infatti, se disabilito le barriers:

/dev/mapper/img1-vm--100--disk--1p1 on /tmp/100 type ext4
(rw,relatime,barrier=0,data=ordered)

ottengo:

CPU BOGOMIPS: 38397.44
REGEX/SECOND: 367438
HD SIZE: 9.39 GB (/dev/mapper/img1-vm--100--disk--1p1)
BUFFERED READS: 183.27 MB/sec
AVERAGE SEEK TIME: 7.66 ms
FSYNCS/SECOND: 746.98
DNS EXT: 137.00 ms
DNS INT: 49.45 ms

Per qualche motivo le barriers non sono abilitate sul filesystem di
default ext3 in pve; pericoloso imho, ma forse non c'è scelta.

rob
g***@public.gmane.org
2014-01-15 09:42:35 UTC
Permalink
Il 15/01/2014 10:06, Roberto Resoli ha scritto:
> quindi le barriers abilitate sembrano fare la differenza.
>

E' detto esplicitamente nel manuale di ext4 di non confrontare le
performance senza allineare le opzioni:

Da https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
> - When comparing performance with other filesystems, it's always
> important to try multiple workloads; very often a subtle change in a
> workload parameter can completely change the ranking of which
> filesystems do well compared to others. When comparing versus ext3,
> note that ext4 enables write barriers by default, while ext3 does
> not enable write barriers by default. So it is useful to use
> explicitly specify whether barriers are enabled or not when via the
> '-o barriers=[0|1]' mount option for both ext3 and ext4 filesystems
> for a fair comparison. When tuning ext3 for best benchmark numbers,
> it is often worthwhile to try changing the data journaling mode; '-o
> data=writeback' can be faster for some workloads. (Note however that
> running mounted with data=writeback can potentially leave stale data
> exposed in recently written files in case of an unclean shutdown,
> which could be a security exposure in some situations.) Configuring
> the filesystem with a large journal can also be helpful for
> metadata-intensive workloads.

gdo
Marco Agostini
2014-01-15 09:49:40 UTC
Permalink
Il 15 gennaio 2014 10:06, Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha scritto:
>
> Per qualche motivo le barriers non sono abilitate sul filesystem di
> default ext3 in pve; pericoloso imho, ma forse non c'è scelta.
>
provo a riassumere:
- disabilitare le barriers senza un controller con batteria (o simile)
è cercare di farsi del male
- al contrario, disabilitare le barriers avendo un controller con
batteria aumenta di una botta le performance

domanda: se non specifico di disabilitare le barriers per un
filesystem ext4.... per default le trovo abilitate ?

per capirci, una cosa di questo tipo indica che le barriers sono "abilitate" ?
/dev/mapper/san1-data on /glusterfs type ext4 (rw,acl,user_xattr)
Roberto Resoli
2014-01-15 10:12:53 UTC
Permalink
Il giorno mer, 15/01/2014 alle 10.49 +0100, Marco Agostini ha scritto:
> Il 15 gennaio 2014 10:06, Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha scritto:
> >
> > Per qualche motivo le barriers non sono abilitate sul filesystem di
> > default ext3 in pve; pericoloso imho, ma forse non c'è scelta.
> >
> provo a riassumere:
> - disabilitare le barriers senza un controller con batteria (o simile)
> è cercare di farsi del male

Anche con la batteria. Le barriers assicurano che l'ordine delle
scritture sia corretto (specie per i filesystems con giornale)

> - al contrario, disabilitare le barriers avendo un controller con
> batteria aumenta di una botta le performance

Non saprei.

> domanda: se non specifico di disabilitare le barriers per un
> filesystem ext4.... per default le trovo abilitate ?

Stando a quanto riportava Guido, si.

> per capirci, una cosa di questo tipo indica che le barriers sono "abilitate" ?
> /dev/mapper/san1-data on /glusterfs type ext4 (rw,acl,user_xattr)

"cat /proc/mounts" dovrebbe darti tutte le opzioni.

rob
Roberto Resoli
2014-01-15 11:34:26 UTC
Permalink
On Mer, 15 Gennaio 2014 11:12, Roberto Resoli wrote:
> Il giorno mer, 15/01/2014 alle 10.49 +0100, Marco Agostini ha scritto:
>> Il 15 gennaio 2014 10:06, Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha
>> scritto:
>> >
>> > Per qualche motivo le barriers non sono abilitate sul filesystem di
>> > default ext3 in pve; pericoloso imho, ma forse non c'è scelta.

non è così: ho appena abilitato le barriers su pve-data, ed ecco il
risultato di pveperf:

pveperf /var/lib/vz
CPU BOGOMIPS: 38397.44
REGEX/SECOND: 369522
HD SIZE: 29.53 GB (/dev/mapper/pve-data)
BUFFERED READS: 185.42 MB/sec
AVERAGE SEEK TIME: 8.24 ms
FSYNCS/SECOND: 32.15
DNS EXT: 92.05 ms
DNS INT: 143.76 ms

rob
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Marco Agostini
2014-01-15 11:40:43 UTC
Permalink
Il 15 gennaio 2014 12:34, Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha scritto:
>
> non è così: ho appena abilitato le barriers su pve-data, ed ecco il
> risultato di pveperf:
>
> pveperf /var/lib/vz
> CPU BOGOMIPS: 38397.44
> REGEX/SECOND: 369522
> HD SIZE: 29.53 GB (/dev/mapper/pve-data)
> BUFFERED READS: 185.42 MB/sec
> AVERAGE SEEK TIME: 8.24 ms
> FSYNCS/SECOND: 32.15
> DNS EXT: 92.05 ms
> DNS INT: 143.76 ms
>

quindi sono esattamente le barriers che vanno ad incidere sulle
prestazioni.... ma come dice Flavio, rimuoverle è comunque andare a
cercar rogne.

Potrei disabilitarle sul mio portatile ! (ricordandomi di spegnerlo
quando la batteria è esausta).
Flavio Stanchina
2014-01-15 11:12:27 UTC
Permalink
Marco Agostini wrote:
> Il 15 gennaio 2014 10:06, Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha scritto:
>>
>> Per qualche motivo le barriers non sono abilitate sul filesystem di
>> default ext3 in pve; pericoloso imho, ma forse non c'è scelta.

Fino a non molto tempo fa le barriers erano disabilitate per default,
anche perché LVM ed il RAID software non avevano un meccanismo per
passare le barrier all'hardware sottostante, rendendole quindi di fatto
inutili se non si stava usando direttamente una partizione fisica.

> provo a riassumere:
> - disabilitare le barriers senza un controller con batteria (o simile)
> è cercare di farsi del male
> - al contrario, disabilitare le barriers avendo un controller con
> batteria aumenta di una botta le performance

Nonononononononononoooooooooo!

Le "barriers" sono le istruzioni che dicono al disco: "garantiscimi che
i dati che ti ho appena mandato sono stati scritti per davvero!"

Se non si chiede esplicitamente il trasferimento di determinati settori
sul disco fisico usando una una barrier, la cache dei dischi moderni
riordina le scritture in modo arbitrario. Questo consente un grosso
aumento di prestazioni (i numeri che hai visto sopra), a discapito della
sicurezza dei tuoi dati.

Con le barriers attive, usare una cache in scrittura è sicuro perché il
file system è sicuro di aver scritto le cose nell'ordine previsto:
questo è *fondamentale* per i file system journaled come ext3 ed ext4,
le cui garanzie di resistenza ai crash si basano proprio sull'ordine nel
quale determinati metadati sono scritti sul disco. Ovviamente le
prestazioni peggiorano, ma senza barriers il disco sta barando
(perdonate l'assonanza).

E qui entra in gioco la cache protetta da batteria dei controller RAID
seri. In questo caso, il controller è autorizzato a soddisfare una
richiesta di barrier quando i dati sono nella sua cache (nota bene: non
in quelle dei dischi, le quali vengono disabilitate!) perché la batteria
garantisce che tali dati sopravviveranno anche in assenza di
alimentazione esterna. E' evidente che le cache interne del sistema
operativo (in RAM) e le cache dei dischi (a loro volta RAM) non
sopravvivono alla mancanza di alimentazione.

Ergo, disabilitare le barriers è *sempre* cercare di farsi del male, a
meno che non siano completamente disabilitate *tutte* le cache in
scrittura; ed alcuni dischi moderni sono famigerati per fare
occasionalmente un minimo di caching anche quando gli hai chiesto di non
farlo, ma tutti devono rispondere alle richieste di barrier
(diversamente sarebbe un bug del firmware).

> domanda: se non specifico di disabilitare le barriers per un
> filesystem ext4.... per default le trovo abilitate ?

Sì. Cerca "barrier" in
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
e troverai una descrizione simile alla mia. Nota che dice:
"If your disks are battery-backed in one way or another, disabling
barriers may safely improve performance."

...ma non ho mai visto *dischi* con una cache protetta da batteria. Su
un controller con cache a batteria, in teoria usare o meno le barrier
non fa differenza perché in ogni caso il controller risponde di aver
recepito i dati quando li ha in cache, ma di certo lasciare attive le
barrier non fa male e ti protegge dal malaugurato caso di una batteria
che si guasta ed il controller che non disattiva la cache in scrittura
(dovrebbe disabilitarla automaticamente in questo caso, ma non si sa mai).

> per capirci, una cosa di questo tipo indica che le barriers sono "abilitate" ?
> /dev/mapper/san1-data on /glusterfs type ext4 (rw,acl,user_xattr)

Stai guardando in /proc/mounts o in /etc/mtab?

In /proc/mounts, barrier=0/1 è scritto esplicitamente perché lo genera
il kernel al volo in base alle opzioni effettivamente in uso, mentre in
/etc/mtab sono scritte solo le opzioni richieste in fstab e/o con il
comando mount, quindi non le opzioni lasciate ai valodi di default.

Ultimamente varie distro hanno eliminato /etc/mtab e lo hanno
trasformato in un symlink a /proc/mounts, in seguito ad alcune modifiche
al kernel che hanno razionalizzato il formato di quest'ultimo file.

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-15 13:04:32 UTC
Permalink
On Mer, 15 Gennaio 2014 12:12, Flavio Stanchina wrote:
...
> Ergo, disabilitare le barriers è *sempre* cercare di farsi del male, a
> meno che non siano completamente disabilitate *tutte* le cache in
> scrittura; ed alcuni dischi moderni sono famigerati per fare
> occasionalmente un minimo di caching anche quando gli hai chiesto di non
> farlo, ma tutti devono rispondere alle richieste di barrier
> (diversamente sarebbe un bug del firmware).

La cosa strana è che pve, anche nella versione 3.1, con un kernel che
permette di attivare o disattivare le barriers sia su ext3 che su ext4,
sceglie ext3, senza barriers.
Leggendo questo thread:

http://forum.proxmox.com/threads/13977-pveperf-and-ext4

pare di capire come la pensa Dietmar:

"Thanks for that link. Glad to see that developers finally see that
performance using barriers is unusable bad (and this is what pveperf shows
exactly?)"

Il link cui si riferisce è questo:

http://lwn.net/Articles/400541/

Da cui si evince che il meccanismo delle barriers è destinato ad essere
abbandonato.

rob
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-15 13:17:06 UTC
Permalink
On Mer, 15 Gennaio 2014 14:04, Roberto Resoli wrote:
...
> pare di capire come la pensa Dietmar:
>
> "Thanks for that link. Glad to see that developers finally see that
> performance using barriers is unusable bad (and this is what pveperf shows
> exactly?)"
>
> Il link cui si riferisce è questo:
>
> http://lwn.net/Articles/400541/
>
> Da cui si evince che il meccanismo delle barriers è destinato ad essere
> abbandonato.

Dato che l'articolo è del 2010, mi piacerebbe capire quanto questo sia
vero per i kernel attuali (proxmox è veramente molto indietro come
versione di kernel); se qualcuno di voi sa o trova informazioni in merito,
sarebbe gentile farlo sapere.

ciao,
rob
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-15 13:38:20 UTC
Permalink
On Mer, 15 Gennaio 2014 14:17, Roberto Resoli wrote:
> On Mer, 15 Gennaio 2014 14:04, Roberto Resoli wrote:
> ...
>> pare di capire come la pensa Dietmar:
>>
>> "Thanks for that link. Glad to see that developers finally see that
>> performance using barriers is unusable bad (and this is what pveperf
>> shows
>> exactly?)"
>>
>> Il link cui si riferisce è questo:
>>
>> http://lwn.net/Articles/400541/
>>
>> Da cui si evince che il meccanismo delle barriers è destinato ad essere
>> abbandonato.
>
> Dato che l'articolo è del 2010, mi piacerebbe capire quanto questo sia
> vero per i kernel attuali (proxmox è veramente molto indietro come
> versione di kernel); se qualcuno di voi sa o trova informazioni in merito,
> sarebbe gentile farlo sapere.

Tanto per iniziare:

https://lkml.org/lkml/2012/11/12/619

"Actually, I'm wondering, why barriers concept is so sticky in the Linux
world? A
simple Google search shows that only Linux uses this concept for storage.
And 2
years passed, since they were removed from the kernel, but people still
discuss
barriers as if they are here."

rob
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Flavio Stanchina
2014-01-15 13:35:04 UTC
Permalink
Roberto Resoli wrote:
> La cosa strana è che pve, anche nella versione 3.1, con un kernel che
> permette di attivare o disattivare le barriers sia su ext3 che su ext4,
> sceglie ext3, senza barriers.

Immagino che sia uno dei motivi per cui non supportano altro che RAID
hardware, nel qual caso non dovrebbe fare differenza se i ragionamenti
delle mie mail precedenti sono corertti.

> Leggendo questo thread:
>
> http://forum.proxmox.com/threads/13977-pveperf-and-ext4
>
> pare di capire come la pensa Dietmar:
>
> "Thanks for that link. Glad to see that developers finally see that
> performance using barriers is unusable bad (and this is what pveperf shows
> exactly?)"

Eh. Le prestazioni di un disco magnetico sono quelle; o ti tieni le
prestazioni sfigate, o abiliti la cache in scrittura e speri che non
vada via la corrente al momento sbagliato.

> Il link cui si riferisce è questo:
>
> http://lwn.net/Articles/400541/
>
> Da cui si evince che il meccanismo delle barriers è destinato ad essere
> abbandonato.

Sì, ma per reimplementare il concetto usando meccanismi meno onerosi per
le prestazioni, però dipende da cosa è in grado di fare il drive (o il
controller RAID). Se svuotare la cache è l'unico modo per garantire la
scrittura dei dati, le prestazioni soffriranno per forza.

http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/Documentation/block/barrier.txt

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-15 14:00:57 UTC
Permalink
On Mer, 15 Gennaio 2014 14:35, Flavio Stanchina wrote:
...
> Se svuotare la cache è l'unico modo per garantire la
> scrittura dei dati, le prestazioni soffriranno per forza.

Il problema è che le barriers sono un overkill, si possono ottenere gli
stessi risultati, con molto minor impatto sulle prestazioni (il minimo
impatto). Per questo sono deprecate da vari anni; non ho ancora capito
comunque, in definitiva, quanto sia sicuro disabilitarle (cioè quanto la
funzionalità sia stata migrata all'interno dei filesystem). Il fatto però
che lo siano su pve 3.1 mi sembra abbastanza indicativo.

rob
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Flavio Stanchina
2014-01-15 14:43:12 UTC
Permalink
Roberto Resoli wrote:
> On Mer, 15 Gennaio 2014 14:35, Flavio Stanchina wrote:
> ...
>> Se svuotare la cache è l'unico modo per garantire la
>> scrittura dei dati, le prestazioni soffriranno per forza.
>
> Il problema è che le barriers sono un overkill, si possono ottenere gli
> stessi risultati, con molto minor impatto sulle prestazioni (il minimo
> impatto). Per questo sono deprecate da vari anni; non ho ancora capito
> comunque, in definitiva, quanto sia sicuro disabilitarle (cioè quanto la
> funzionalità sia stata migrata all'interno dei filesystem). Il fatto però
> che lo siano su pve 3.1 mi sembra abbastanza indicativo.

Ah, interessante; dopo averti risposto ho seguito meglio i collegamenti
che hai passato (ed i vari thread a cui portavano) ed ho capito che le
barrier come originariamente implementate non dovrebbero più esserci, ma
non ho capito come facciano ora a garantire la scrittura in ordine del
journal e come sia in pratica implementata fsync().

Comunque per scrupolo ho fatto alcuni test sui due PVE con un solo disco
SATA ed i risultati indicano abbastanza chiaramente che spegnere la
cache in scrittura o abilitare le barrier sia ugualmente deleterio per
le prestazioni. C'è da notare che:
* è il kernel 2.6.32 di PVE, mi aspetterei numeri diversi dai kernel
odierni se è vero che il meccanismo è stato rivisto e migliorato;
* i test sono stati fatti a macchine scariche, quindi c'erano solo le
fsync di pveperf a far girare il disco: in una situazione reale, dove le
fsync sono mescolate a scritture random, mi aspetto che le barrier
abbiano un impatto minore rispetto a disabilitare completamente la
cache. Magari un giorno mi metto a fare qualche prova.

== con write cache spenta
hdparm -W0 /dev/sda

1# pveperf /home/
BUFFERED READS: 78.79 MB/sec
AVERAGE SEEK TIME: 8.39 ms
FSYNCS/SECOND: 27.13

2# pveperf /home/
BUFFERED READS: 69.51 MB/sec
AVERAGE SEEK TIME: 11.92 ms
FSYNCS/SECOND: 38.64

== con write cache accesa, barrier=0
hdparm -W1 /dev/sda

1# pveperf /home/
BUFFERED READS: 44.78 MB/sec
AVERAGE SEEK TIME: 8.54 ms
FSYNCS/SECOND: 991.28

2# pveperf /home/
BUFFERED READS: 70.49 MB/sec
AVERAGE SEEK TIME: 13.37 ms
FSYNCS/SECOND: 924.23

== con write cache accesa, barrier=1
mount /home/ -o remount,barrier=1

1# pveperf /home/
BUFFERED READS: 79.79 MB/sec
AVERAGE SEEK TIME: 8.30 ms
FSYNCS/SECOND: 34.87

2# pveperf /home/
BUFFERED READS: 71.71 MB/sec
AVERAGE SEEK TIME: 7.46 ms
FSYNCS/SECOND: 37.93

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-15 15:03:24 UTC
Permalink
On Mer, 15 Gennaio 2014 15:43, Flavio Stanchina wrote:
> Roberto Resoli wrote:
...
> le barriers sono un overkill, si possono ottenere gli
>> stessi risultati, con molto minor impatto sulle prestazioni (il minimo
>> impatto). Per questo sono deprecate da vari anni; non ho ancora capito
>> comunque, in definitiva, quanto sia sicuro disabilitarle (cioè quanto
>> la
>> funzionalità  sia stata migrata all'interno dei filesystem). Il fatto
>> però
>> che lo siano su pve 3.1 mi sembra abbastanza indicativo.
>
> Ah, interessante; dopo averti risposto ho seguito meglio i collegamenti
> che hai passato (ed i vari thread a cui portavano) ed ho capito che le
> barrier come originariamente implementate non dovrebbero più esserci, ma
> non ho capito come facciano ora a garantire la scrittura in ordine del
> journal e come sia in pratica implementata fsync().

Il tutto è spiegato abbastanza
bene nel famoso articolo "The end of block barriers":

"in the real world, barriers are implemented by simply draining the I/O
request queue prior to issuing the barrier operation, with some flush
operations thrown in to get the hardware to actually commit the data to
persistent media. Queue-drain operations will stall the device and kill
the parallelism needed for full performance; it's not surprising that the
use of barriers can be painful.

In their discussions of this problem, the storage and filesystem
developers have realized that the ordering semantics provided by
block-layer barriers are much stronger than necessary. Filesystems need to
ensure that certain requests are executed in a specific order, and they
need to ensure that specific requests have made it to the physical media
before starting others. Beyond that, though, filesystems need not concern
themselves with the ordering for most other requests, so the use of
barriers constrains the block layer more than is required. In general, it
was concluded, filesystems should concern themselves with ordering, since
that's where the information is, and not dump that problem into the block
layer. "

Inoltre, nello stesso articolo è linkato questo post:

"replace barriers with explicit flush / FUA usage "
http://lwn.net/Articles/400777/

nel commento si legge, tra l'altro "This series converts over all
filesystems to the new WRITE_FLUSH_FUA primitive that Tejun added. XFS,
btrfs, gfs2, reiserfs, ext3 and ext4
have passed extensive xfstests coverage with this, while ocfs2, nilfs2
and fat are unsupposed by xfstests and thus untested in this patch."

>
> Comunque per scrupolo ho fatto alcuni test sui due PVE con un solo disco
> SATA ed i risultati indicano abbastanza chiaramente che spegnere la
> cache in scrittura o abilitare le barrier sia ugualmente deleterio per
> le prestazioni.

Da quello che capisco le barrier non servono più, perchè il filesystem (e
gli strati md, dm , ecc eventuali al di sotto) si sono evoluti abbastanza
da non richiederle più.

Ovviamente disabilitare tout-court la cache in scrittura ha un effetto
ancora più deleterio sulle prestazioni, rispetto all'abilitazione delle
barrier con cache attiva.

C'è da notare che:
> * è il kernel 2.6.32 di PVE, mi aspetterei numeri diversi dai kernel
> odierni se è vero che il meccanismo è stato rivisto e migliorato;

Attenzione che il kernel è quello di redhat, con numerosi backporting
dalle versioni successive.
Da vari accenni in rete ho sentore che già questo kernel recepisca la
deprecazione delle barrier
(le famose patch originali di Tejun Heo: https://lkml.org/lkml/2010/9/3/199 )

> * i test sono stati fatti a macchine scariche, quindi c'erano solo le
> fsync di pveperf a far girare il disco: in una situazione reale, dove le
> fsync sono mescolate a scritture random, mi aspetto che le barrier
> abbiano un impatto minore rispetto a disabilitare completamente la
> cache.

E' così; ma perchè disabilitare la cache?

ciao,
rob
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Flavio Stanchina
2014-01-15 16:43:10 UTC
Permalink
Roberto Resoli wrote:
> On Mer, 15 Gennaio 2014 15:43, Flavio Stanchina wrote:
>> Ah, interessante; dopo averti risposto ho seguito meglio i collegamenti
>> che hai passato (ed i vari thread a cui portavano) ed ho capito che le
>> barrier come originariamente implementate non dovrebbero più esserci, ma
>> non ho capito come facciano ora a garantire la scrittura in ordine del
>> journal e come sia in pratica implementata fsync().
>
> Il tutto è spiegato abbastanza
> bene nel famoso articolo "The end of block barriers": [...]

Aaaah bene, adesso è tutto chiaro. Questo documento è interessante:
http://lxr.free-electrons.com/source/Documentation/block/writeback_cache_control.txt

> Da quello che capisco le barrier non servono più, perchè il filesystem (e
> gli strati md, dm , ecc eventuali al di sotto) si sono evoluti abbastanza
> da non richiederle più.

L'ultima domanda rimasta è dunque:
perché ext3 ed ext4 hanno ancora il parametro barrier se non serve più?

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-16 07:57:28 UTC
Permalink
Flavio Stanchina <flavio-***@public.gmane.org> ha scritto:
>Roberto Resoli wrote:
>> On Mer, 15 Gennaio 2014 15:43, Flavio Stanchina wrote:
>>> Ah, interessante; dopo averti risposto ho seguito meglio i
>collegamenti
>>> che hai passato (ed i vari thread a cui portavano) ed ho capito che
>le
>>> barrier come originariamente implementate non dovrebbero più
>esserci, ma
>>> non ho capito come facciano ora a garantire la scrittura in ordine
>del
>>> journal e come sia in pratica implementata fsync().
>>
>> Il tutto è spiegato abbastanza
>> bene nel famoso articolo "The end of block barriers": [...]
>
>Aaaah bene, adesso è tutto chiaro. Questo documento è interessante:
>http://lxr.free-electrons.com/source/Documentation/block/writeback_cache_control.txt
>
>> Da quello che capisco le barrier non servono più, perchè il
>filesystem (e
>> gli strati md, dm , ecc eventuali al di sotto) si sono evoluti
>abbastanza
>> da non richiederle più.
>
>L'ultima domanda rimasta è dunque:
>perché ext3 ed ext4 hanno ancora il parametro barrier se non serve più?

Backward compatibility, in parte. Comunque, guardate qui la spiegazione per cui pve usa barrier=0 su ext3:

http://forum.proxmox.com/threads/15439-Slow-IO-performance-with-LVM-and-no-RAID?p=82390#post82390

rob

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-16 08:10:54 UTC
Permalink
Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha scritto:
>Flavio Stanchina <flavio-***@public.gmane.org> ha scritto:
>>Roberto Resoli wrote:
...
>>L'ultima domanda rimasta è dunque:
>>perché ext3 ed ext4 hanno ancora il parametro barrier se non serve
>più?
>
>Backward compatibility, in parte. Comunque, guardate qui la spiegazione
>per cui pve usa barrier=0 su ext3:
>
>http://forum.proxmox.com/threads/15439-Slow-IO-performance-with-LVM-and-no-RAID?p=82390#post82390

La lettura lascia un po' sconcertati. Non sembra che la deprecazione delle barrier sia stata considerata, e il fatto che dietmar sostenga: " Also, running ext4 with barrier=0 is considered unsafe (ext3 is known to work without problems)" senza giustificarne il motivo non rincuora granchè.

rob


--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Marco Agostini
2014-01-16 09:55:25 UTC
Permalink
Il 16 gennaio 2014 09:10, Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha scritto:
>
> La lettura lascia un po' sconcertati. Non sembra che la deprecazione delle barrier sia stata considerata, e il fatto che dietmar sostenga: " Also, running ext4 with barrier=0 is considered unsafe (ext3 is known to work without problems)" senza giustificarne il motivo non rincuora granchè.
>
Direi di si.

Leggendo bene il thread si trova anche questo:

---------------------------------------------------------------
Using ext4 with barrier=0 is as safe as using ext3 with barrier=0 due
to the new default mount option:

Code:

auto_da_alloc(*) Many broken applications don't use fsync() when
noauto_da_alloc replacing existing files via patterns such as
fd = open("foo.new")/write(fd,..)/close(fd)/
rename("foo.new", "foo"), or worse yet,
fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).
If auto_da_alloc is enabled, ext4 will detect
the replace-via-rename and replace-via-truncate
patterns and force that any delayed allocation
blocks are allocated such that at the next
journal commit, in the default data=ordered
mode, the data blocks of the new file are forced
to disk before the rename() operation is
committed. This provides roughly the same level
of guarantees as ext3, and avoids the
"zero-length" problem that can happen when a
system crashes before the delayed allocation
blocks are forced to disk.
---------------------------------------------------------------

la parte di "Code:" è tratta da qui
https://www.kernel.org/doc/Documentation/filesystems/ext4.txt

Hai modo/tempo per fare un test abilitando auto_da_alloc e
disabilitando barrier su un ext4 ?
Flavio Stanchina
2014-01-16 10:23:43 UTC
Permalink
Marco Agostini wrote:
> Leggendo bene il thread si trova anche questo:
>
> ---------------------------------------------------------------
> Using ext4 with barrier=0 is as safe as using ext3 with barrier=0 due
> to the new default mount option:
>
> Code:
>
> auto_da_alloc(*) Many broken applications don't use fsync() when [...]
> ---------------------------------------------------------------
>
> la parte di "Code:" è tratta da qui
> https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
>
> Hai modo/tempo per fare un test abilitando auto_da_alloc e
> disabilitando barrier su un ext4 ?

auto_da_alloc è abilitato per default.

Risolve un problema completamente diverso dalle barrier, ossia
applicazioni che rimpiazzano un file ma *non* chiamano fsync() nei due
casi descritti: in caso di crash, i file appena creati non conterranno i
dati giusti perché il kernel non li aveva ancora scritti (nemmeno nella
cache del disco!) visto che non gli era stato imposto con una fsync() e
l'algoritmo di allocazione ritardata stava aspettando altri dati per
decidere dove scriverli (vedere opzione delalloc in
Documentation/filesystems/ext4.txt).

E' importante ricordare che tutte queste sottigliezze sono rilevanti
solo in caso di crash del sistema o -- peggio -- di mancanza imprevista
della corrente. Le barrier in particolare (o meccanismi equivalenti)
sono rilevanti solo nel secondo caso, perché in caso di crash o blocco
del kernel il disco avrà ovviamente tutto il tempo di scrivere i dati
che aveva già in cache.

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Marco Agostini
2014-01-16 10:42:36 UTC
Permalink
Il 16 gennaio 2014 11:23, Flavio Stanchina <flavio-***@public.gmane.org> ha scritto:
>
> E' importante ricordare che tutte queste sottigliezze sono rilevanti solo in
> caso di crash del sistema o -- peggio -- di mancanza imprevista della
> corrente. Le barrier in particolare (o meccanismi equivalenti) sono
> rilevanti solo nel secondo caso, perché in caso di crash o blocco del kernel
> il disco avrà ovviamente tutto il tempo di scrivere i dati che aveva già in
> cache.
>
Quello che ancora però non capisco è il rischio effettivo di una
mancanza di corrente improvvisa (es. l'ups non si comporta come
dovrebbe o le procedure di spegnimento automatico non vanno a buon
fine.... e la batteria del controller raid è anche scarica).

Significa che il filesystem potrebbe essere completamente corrotto e
quindi non più recuperabile ?

O più semplicemente che potrei, nel caso ad esempio di una scrittura
intensiva su di un db, perdere la scrittura di qualche record ?
Matteo Ragni
2014-01-16 10:47:11 UTC
Permalink
Il giorno 16 gennaio 2014 11:42, Marco Agostini <comunelevico-***@public.gmane.org> ha
scritto:

> Quello che ancora però non capisco Ú il rischio effettivo di una
> mancanza di corrente improvvisa
>

Da quello che so, e non Ú molto,
*almeno che tu non stia facendo delle operazioni particolari sulla
partizione stessa*
allora dovrebbe limitarsi alla perdita di qualche dato, che non Ú detto che
non sia una situazione irrecuperabile.


--
distinti saluti,

------------
Matteo Ragni
------------

<aka: nirvana1289> # reply to: nirvana1289-***@public.gmane.org
GPG Public Key: 0x0141EDBD238098A0 @ pgp.mit.edu
gpg --keyserver pgp.mit.edu --recv-key 0x0141EDBD238098A0
Flavio Stanchina
2014-01-16 16:10:34 UTC
Permalink
Marco Agostini wrote:
> Quello che ancora però non capisco è il rischio effettivo di una
> mancanza di corrente improvvisa [...]
>
> Significa che il filesystem potrebbe essere completamente corrotto e
> quindi non più recuperabile ?

Generalmente no, già ext2 era tutto sommato abbastanza robusto in caso
di crash; ma il rischio c'è, dipende da cosa stava succedendo in quel
momento. In ogni caso, il file system è da considerarsi corrotto ed è
necessario fare un fsck completo. Ragionevolmente perderai al massimo
qualche file, ma se per ipotesi stavi creando una nuova directory nella
root del file system potresti sputtanare tutta la directory principale e
dopo un fsck ritrovarti con il file system semivuoto ed un'accozzaglia
di file e directory in lost+found, senza più il loro nome originale. Auguri.

Le barrier (o meccanismo equivalente ma meno deleterio per le
prestazioni del sistema) servono proprio per questo: un file system
journaled o log-based ti *garantisce* che in caso di crash perderai al
massimo una manciata delle ultime operazioni eseguite, ma solo se il
disco che ci sta sotto ha scritto i dati nell'ordine richiesto dal file
system. Le cache in scrittura che riordinano arbitrariamente le
richieste non danno questa garanzia.

> O più semplicemente che potrei, nel caso ad esempio di una scrittura
> intensiva su di un db, perdere la scrittura di qualche record ?

Con un database il discorso si fa complesso, come spiega questo articolo
sull'uso di sqlite in Firefox (mi pare che sia già stato linkato in un
messaggio precedente):
http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/

Un file di database ha una struttura complessa: se alcune parti del file
non sono state scritte nell'ordine giusto, è abbastanza probabile
perdere tutto il contenuto del database (o della tabella, nei database
che hanno un file per tabella).

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Marco Agostini
2014-01-16 17:30:14 UTC
Permalink
Il giorno 16/gen/2014 17:11, "Flavio Stanchina" <flavio-***@public.gmane.org> ha
scritto:
>
> Un file di database ha una struttura complessa: se alcune parti del file
non sono state scritte nell'ordine giusto, è abbastanza probabile perdere
tutto il contenuto del database (o della tabella, nei database che hanno un
file per tabella).
>
Immagino che la cosa valga anche per i file qcow utilizzati per la
virtualizzazione.
g***@public.gmane.org
2014-01-16 11:05:39 UTC
Permalink
Il 16/01/2014 11:23, Flavio Stanchina ha scritto:
> ===CUT===
>
> E' importante ricordare che tutte queste sottigliezze sono rilevanti
> solo in caso di crash del sistema o -- peggio -- di mancanza
> imprevista della corrente. Le barrier in particolare (o meccanismi
> equivalenti) sono rilevanti solo nel secondo caso, perché in caso di
> crash o blocco del kernel il disco avrà ovviamente tutto il tempo di
> scrivere i dati che aveva già in cache.
>

Quindi se cosi è con un server sotto gruppo di continuità con lo
shutdown gestito posso fidarmi a disabilitare le barrier.

Dato che un UPS gestito per l'alimentazione di un server è ormai "di
serie" prevederlo, utilizzare un RAID software non trovo sia una
"bestemmia".

Ovviamente si spera che nessuno inciampi nella presa ;-)

ciao
Guido

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Flavio Stanchina
2014-01-16 15:41:45 UTC
Permalink
gdo-***@public.gmane.org wrote:
> Quindi se cosi è con un server sotto gruppo di continuità con lo
> shutdown gestito posso fidarmi a disabilitare le barrier.

Ognuno decide per sé fin dove fidarsi, basta essere informati sui
rischi. Indubbiamente un server con UPS gestito presenta meno rischi di
un server domestico attaccato alla stessa linea della lavastoviglie.

> Dato che un UPS gestito per l'alimentazione di un server è ormai "di
> serie" prevederlo, utilizzare un RAID software non trovo sia una
> "bestemmia".

Il problema non è RAID software o hardware: il problema è abilitare o
meno la cache in scrittura dei dischi o quella del controller se non è
protetta da batteria.

Alcuni controller RAID hardware non permettono proprio di abilitare la
cache in scrittura (write-back) se non c'è la batteria.

> Ovviamente si spera che nessuno inciampi nella presa ;-)

Hic sunt leones.

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-16 12:11:18 UTC
Permalink
On Gio, 16 Gennaio 2014 10:55, Marco Agostini wrote:
> Il 16 gennaio 2014 09:10, Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha
> scritto:
>>
>> La lettura lascia un po' sconcertati. Non sembra che la deprecazione
>> delle barrier sia stata considerata, e il fatto che dietmar sostenga: "
>> Also, running ext4 with barrier=0 is considered unsafe (ext3 is known to
>> work without problems)" senza giustificarne il motivo non rincuora
>> granchè.
>>
> Direi di si.
>
> Leggendo bene il thread si trova anche questo:
>
> ---------------------------------------------------------------
> Using ext4 with barrier=0 is as safe as using ext3 with barrier=0 due
> to the new default mount option:

Certo, ma "as safe as" non significa safe! Quello che il tizio vuole dire
è che disabilitare le barriers su ext4 è tanto sicuro quanto lo è su ext3
(cioè poco secondo lui, dato che poi cita un'articolo del 2008 di cui
abbiamo parlato a suo tempo anche qui, ignorando che le barriers sono
deprecate almeno dal 2012).

rob
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Roberto Resoli
2014-01-16 12:36:18 UTC
Permalink
On Gio, 16 Gennaio 2014 13:11, Roberto Resoli wrote:
..
> Certo, ma "as safe as" non significa safe! Quello che il tizio vuole dire
> è che disabilitare le barriers su ext4 è tanto sicuro quanto lo è su ext3
> (cioè poco secondo lui, dato che poi cita un'articolo del 2008 di cui
> abbiamo parlato a suo tempo anche qui, ignorando che le barriers sono
> deprecate almeno dal 2012).

Ho aperto un thread apposito sul forum di proxmox:

http://forum.proxmox.com/threads/17543-barriers-deprecation-and-pve?p=89248#post89248

rob

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Marco Agostini
2014-01-15 15:00:58 UTC
Permalink
Il 15 gennaio 2014 15:00, Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha scritto:
>
> Il problema è che le barriers sono un overkill, si possono ottenere gli
> stessi risultati, con molto minor impatto sulle prestazioni (il minimo
> impatto). Per questo sono deprecate da vari anni; non ho ancora capito
> comunque, in definitiva, quanto sia sicuro disabilitarle (cioè quanto la
> funzionalità sia stata migrata all'interno dei filesystem). Il fatto però
> che lo siano su pve 3.1 mi sembra abbastanza indicativo.
>
tanto per buttare altra carne al fuoco.... e per quanto riguarda le
barriers impostate o meno direttamente nelle macchine virtuali ?

visto che i livelli software aumentano ?
Roberto Resoli
2014-01-15 15:12:28 UTC
Permalink
On Mer, 15 Gennaio 2014 16:00, Marco Agostini wrote:
> Il 15 gennaio 2014 15:00, Roberto Resoli <roberto-eM3ggUIyDrJv+3K+***@public.gmane.org> ha
> scritto:
>>
>> Il problema è che le barriers sono un overkill, si possono ottenere gli
>> stessi risultati, con molto minor impatto sulle prestazioni (il minimo
>> impatto). Per questo sono deprecate da vari anni; non ho ancora capito
>> comunque, in definitiva, quanto sia sicuro disabilitarle (cioè quanto la
>> funzionalità sia stata migrata all'interno dei filesystem). Il fatto
>> però
>> che lo siano su pve 3.1 mi sembra abbastanza indicativo.
>>
> tanto per buttare altra carne al fuoco.... e per quanto riguarda le
> barriers impostate o meno direttamente nelle macchine virtuali ?

Infatti; la butto lì: a naso le barriers non dovrebbero servire nemmeno
sulle vm, posto
che il block device virtuale implementi adeguatamente REQ_FLUSH/FUA

rob

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Francesco Gabriele
2014-01-15 10:09:10 UTC
Permalink
Salve,

mi aggiungo all'argomento anche se nel dettaglio io devo installare un
debian pura senza virtualizzazione su questo controller, volevo chiede se
poi il raid software qualcuno è riuscito ad installarlo, perche a me dopo
l'installazione grub mi da errore e non parte.
Sto usando una Debian Wheezy ed il controller è impostato con due Array
singoli da un solo disco ad array.

Grazie


----
Francesco Gabriele

Blog - www.ubuntuserver.it
Linux users #5484 Frank (IT)
Asterisk users #852 Frankies (IT)
Marco Ciampa
2014-01-16 10:04:40 UTC
Permalink
On Wed, Jan 15, 2014 at 11:09:10AM +0100, Francesco Gabriele wrote:
> Salve,
>
> mi aggiungo all'argomento anche se nel dettaglio io devo installare un
> debian pura senza virtualizzazione su questo controller, volevo chiede se
> poi il raid software qualcuno è riuscito ad installarlo, perche a me dopo
> l'installazione grub mi da errore e non parte.
> Sto usando una Debian Wheezy ed il controller è impostato con due Array
> singoli da un solo disco ad array.

Visto che i discho vengono visti come unità separate il problema non deve
essere l'hardware. Io la Debian con RAID sw 1 l'ho sempre installata
senza problemi.

Occhio che GRUB lo devi installare su tutti e due i dischi. Nel dubbio poi fai:

grub-install /dev/sda
grub-install /dev/sdb

bye

--


Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana
di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci
passi. Per quanto cammini, non la raggiungerò mai. A cosa serve
l'utopia? A questo: serve a camminare." Eduardo Galeano

+--------------------+
| Linux User #78271 |
| FSFE fellow #364 |
+--------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Matteo Ragni
2014-01-16 10:22:45 UTC
Permalink
Anche seguendo questa guida? [1]
Io l'ho utilizzata per fare il raid1 di due chiavette usb che uso come
disco di sistema sul mio server. Ammetto che neanche questa guida mi aveva
aiutato: il mio problema era creare una piccolia partizione avviabile sul
disco sda (da 3TB) dell'LVM per installare grub. Poi tutto ha funzionato
egregiamente. Inoltre era necessario inserire un delay di avvio per dare il
tempo al raid di crearsi in avvio (boot flag: rootdelay=20).
Il server vecchio aveva due hdd nel raid1 del sistema, sda e sdb, uniti
diventavano md0, ma tutto ha funzionato subito dopo l'installazione, senza
altri magheggiamenti.

[1]: https://wiki.debian.org/DebianInstaller/SataRaid



Il giorno 16 gennaio 2014 11:04, Marco Ciampa <ciampix-VGgt2q2+T+***@public.gmane.org> ha
scritto:

> On Wed, Jan 15, 2014 at 11:09:10AM +0100, Francesco Gabriele wrote:
> > Salve,
> >
> > mi aggiungo all'argomento anche se nel dettaglio io devo installare un
> > debian pura senza virtualizzazione su questo controller, volevo chiede se
> > poi il raid software qualcuno Ú riuscito ad installarlo, perche a me dopo
> > l'installazione grub mi da errore e non parte.
> > Sto usando una Debian Wheezy ed il controller Ú impostato con due Array
> > singoli da un solo disco ad array.
>
> Visto che i discho vengono visti come unità separate il problema non deve
> essere l'hardware. Io la Debian con RAID sw 1 l'ho sempre installata
> senza problemi.
>
> Occhio che GRUB lo devi installare su tutti e due i dischi. Nel dubbio poi
> fai:
>
> grub-install /dev/sda
> grub-install /dev/sdb
>
> bye
>
> --
>
>
> Marco Ciampa
>
> "L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana
> di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci
> passi. Per quanto cammini, non la raggiungerò mai. A cosa serve
> l'utopia? A questo: serve a camminare." Eduardo Galeano
>
> +--------------------+
> | Linux User #78271 |
> | FSFE fellow #364 |
> +--------------------+
>
> --
> Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
> "subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
>
>
>


--
distinti saluti,

------------
Matteo Ragni
------------

<aka: nirvana1289> # reply to: nirvana1289-***@public.gmane.org
GPG Public Key: 0x0141EDBD238098A0 @ pgp.mit.edu
gpg --keyserver pgp.mit.edu --recv-key 0x0141EDBD238098A0
Marco Ciampa
2014-01-16 12:00:00 UTC
Permalink
On Thu, Jan 16, 2014 at 11:22:45AM +0100, Matteo Ragni wrote:
> Anche seguendo questa guida? [1]

Fake raid? No no no no no no a meno che tu non abbia RAID1 in dual boot Windows...

> Io l'ho utilizzata per fare il raid1 di due chiavette usb che uso come
> disco di sistema sul mio server.

Fake raid su USB???? Ma sei pazzo? ;-)

> Ammetto che neanche questa guida mi aveva
> aiutato: il mio problema era creare una piccolia partizione avviabile sul
> disco sda (da 3TB) dell'LVM per installare grub.

Che nelle ultime Debian non serve...

> Poi tutto ha funzionato egregiamente.

> Inoltre era necessario inserire un delay di avvio per dare il
> tempo al raid di crearsi in avvio (boot flag: rootdelay=20).

Mai servito.

> Il server vecchio aveva due hdd nel raid1 del sistema, sda e sdb, uniti
> diventavano md0,

quindi non è fake raid... che cavolo stai dicendo Willis? [TM]

> ma tutto ha funzionato subito dopo l'installazione, senza
> altri magheggiamenti.
>
> [1]: https://wiki.debian.org/DebianInstaller/SataRaid

--


Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana
di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci
passi. Per quanto cammini, non la raggiungerò mai. A cosa serve
l'utopia? A questo: serve a camminare." Eduardo Galeano

+--------------------+
| Linux User #78271 |
| FSFE fellow #364 |
+--------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Matteo Ragni
2014-01-16 13:08:12 UTC
Permalink
Il giorno 16 gennaio 2014 13:00, Marco Ciampa <ciampix-VGgt2q2+T+***@public.gmane.org> ha
scritto:

> quindi non Ú fake raid... che cavolo stai dicendo Willis?


Hai ragionissima. Ero convinto che fake raid e software raid fossero la
stessa cosa. ERRORE MIO!

> Ammetto che neanche questa guida mi aveva
> > aiutato: il mio problema era creare una piccolia partizione avviabile sul
> > disco sda (da 3TB) dell'LVM per installare grub.
> Che nelle ultime Debian non serve...


bÚ a me era solo servita la parte che mi permetteva di avviare il sistema
per il ripristino. Non lo avevo mai fatto prima e lì Ú descritto molto
bene... Comunque Ú l'ultima versione di debian e ha bisogno ancora della
partizione con la flag grub_boot per avviare grub dal disco di dimensioni
maggiore di 2TB...
Tu ci riesci senza? se sì come?
E del software raid con due chiavette usb che dici? ti sembra sempre una
pessima idea?
Ú stata una scelta praticamente costretta, il server supporta 4 dischi SATA
e uso tutti gli slot per l'LVM, quindi ho pensato di mettere tutto il
sistema sulla chiavetta...


--
distinti saluti,

------------
Matteo Ragni
------------

<aka: nirvana1289> # reply to: nirvana1289-***@public.gmane.org
GPG Public Key: 0x0141EDBD238098A0 @ pgp.mit.edu
gpg --keyserver pgp.mit.edu --recv-key 0x0141EDBD238098A0
Marco Ciampa
2014-01-16 15:06:51 UTC
Permalink
On Thu, Jan 16, 2014 at 02:08:12PM +0100, Matteo Ragni wrote:
> Il giorno 16 gennaio 2014 13:00, Marco Ciampa <ciampix-VGgt2q2+T+***@public.gmane.org> ha
> scritto:
>
> > quindi non è fake raid... che cavolo stai dicendo Willis?
>
> Hai ragionissima. Ero convinto che fake raid e software raid fossero la
> stessa cosa. ERRORE MIO!

Non ti preoccupare, non volevo puntualizzare l'errore, era per evitare
malintesi.

> > Ammetto che neanche questa guida mi aveva
> > > aiutato: il mio problema era creare una piccolia partizione avviabile sul
> > > disco sda (da 3TB) dell'LVM per installare grub.
> > Che nelle ultime Debian non serve...
>
>
> bè a me era solo servita la parte che mi permetteva di avviare il sistema
> per il ripristino.

beh male non fa.

> Non lo avevo mai fatto prima e lì è descritto molto bene...
> Comunque è l'ultima versione di debian e ha bisogno ancora della
> partizione con la flag grub_boot per avviare grub dal disco di dimensioni
> maggiore di 2TB...

Ma non basta fare una tabella partizioni GPT?

> Tu ci riesci senza? se sì come?

Con le partizioni GPT?

> E del software raid con due chiavette usb che dici? ti sembra sempre una
> pessima idea?

Beh no. Le prestazioni son pessime e si rovinano facilmente a scriverle,
ma se serve solo per la boot, quindi caricare il kernel senza scrivere
quasi mai non è poi male come idea....anzi quasi quasi te la copio...

> è stata una scelta praticamente costretta, il server supporta 4 dischi SATA
> e uso tutti gli slot per l'LVM, quindi ho pensato di mettere tutto il
> sistema sulla chiavetta...

si si adesso capisco, perfettamente logico...


--


Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana
di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci
passi. Per quanto cammini, non la raggiungerò mai. A cosa serve
l'utopia? A questo: serve a camminare." Eduardo Galeano

+--------------------+
| Linux User #78271 |
| FSFE fellow #364 |
+--------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Matteo Ragni
2014-01-16 15:50:02 UTC
Permalink
Il giorno 16 gennaio 2014 16:06, Marco Ciampa <ciampix-VGgt2q2+T+***@public.gmane.org> ha
scritto:

> > Tu ci riesci senza? se sì come?
>
> Con le partizioni GPT?


c'Ú, ma grub-install spara un overflow in console senza quella partizione
grub_boot all'inizio del disco.

(P.S. hai fatto benissimo a puntualizzare l'errore. Fatelo sempre! io
scrivo qui per imparare e condividere quel poco che scopro sulla mia pelle)

Beh no. Le prestazioni son pessime e si rovinano facilmente a scriverle,
> ma se serve solo per la boot, quindi caricare il kernel senza scrivere
> quasi mai non Ú poi male come idea....anzi quasi quasi te la copio...


ecco qui si apre il problema che ho adesso. Il contenuto fisico del server
mysql, lo vorrei spostare nell'LVM. Qualcuno ha mai provato a fare una cosa
del genere?
--
distinti saluti,

------------
Matteo Ragni
------------

<aka: nirvana1289> # reply to: nirvana1289-***@public.gmane.org
GPG Public Key: 0x0141EDBD238098A0 @ pgp.mit.edu
gpg --keyserver pgp.mit.edu --recv-key 0x0141EDBD238098A0
Flavio Stanchina
2014-01-16 16:27:10 UTC
Permalink
Matteo Ragni wrote:
> Il giorno 16 gennaio 2014 16:06, Marco Ciampa ha scritto:
>
> Beh no. Le prestazioni son pessime e si rovinano facilmente a scriverle,
> ma se serve solo per la boot, quindi caricare il kernel senza scrivere
> quasi mai non è poi male come idea....anzi quasi quasi te la copio...
>
>
> ecco qui si apre il problema che ho adesso. Il contenuto fisico del
> server mysql, lo vorrei spostare nell'LVM. Qualcuno ha mai provato a
> fare una cosa del genere?

Ma sulle chiavette hai solo /boot come ipotizzava Marco, o hai tutto il
sistema operativo? Ho dato un'occhiata ai messaggi precedenti del thread
ma sinceramente non sono sicuro di aver capito.

Sinceramente ci metterei solo /boot che viene toccata solo raramente,
così sei abbastanza sicuro che le chiavette non si usurino in poco
tempo. La root la metterei su un volume LVM dei dischi rigidi. In questo
caso, per migrare il tuo sistema bisogna smanettare un po' con una live
ma non è niente di esoterico.

--
Ciao, Flavio
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Matteo Ragni
2014-01-16 16:38:50 UTC
Permalink
> Ma sulle chiavette hai solo /boot come ipotizzava Marco, o hai tutto il
> sistema operativo? Ho dato un'occhiata ai messaggi precedenti del thread ma
> sinceramente non sono sicuro di aver capito.
>
> Sinceramente ci metterei solo /boot che viene toccata solo raramente, così
> sei abbastanza sicuro che le chiavette non si usurino in poco tempo. La
> root la metterei su un volume LVM dei dischi rigidi. In questo caso, per
> migrare il tuo sistema bisogna smanettare un po' con una live ma non Ú
> niente di esoterico.


Tutto il sistema. Gli accessi in scrittura e lettura sono pochissimi
(spostando la tmp e parte della var come cache e lock in ram all'avvio,
seguendo un bellissimo articolo di linux pro che ora non ho sotto mano).
Ovvimanente le prestazioni sono inferiori rispetto ai due barracuda 10000
rpm che avevo prima, ma a parte il rootdelay in boot non si nota...

Il server vecchio Ú rimasto praticamente inalterato per 3 anni (lo cambio
per risparmio energetico), quindi non Ú che faccia nulla di che...


--
distinti saluti,

------------
Matteo Ragni
------------

<aka: nirvana1289> # reply to: nirvana1289-***@public.gmane.org
GPG Public Key: 0x0141EDBD238098A0 @ pgp.mit.edu
gpg --keyserver pgp.mit.edu --recv-key 0x0141EDBD238098A0
Nicola Ferrari (#554252)
2014-01-05 11:06:29 UTC
Permalink
In aggiunta alla mail precedente
Per la cronaca i dischi "locali" li uso solo per il s.o. e per backup.
Per le immagini delle vm c'e' uno storage condiviso, quindi forse e' un
buon compromesso!

La cosa piu' difficile e' andare a spiegare ai miei "ragionieri" che
bisogna prendere altro ferro :) Mi fa specie che una macchina di quella
fascia (che non e' eccelsa ma nemmeno cosi' schifosa, ed e' comunque un
server) abbia fake raid. I proliant 380Gen6 di qualche hanno fa non solo
avevano raid hw, ma era anche serio.. :)

Ciao, buona domenica,
N

--
+---------------------+
| Linux User #554252 |
+---------------------+
Marco Agostini
2014-01-05 13:11:55 UTC
Permalink
Il giorno 05/gen/2014 12:06, "Nicola Ferrari (#554252)" <nicolafrr-***@public.gmane.org>
ha scritto:
>
> In aggiunta alla mail precedente
> Per la cronaca i dischi "locali" li uso solo per il s.o. e per backup.
> Per le immagini delle vm c'e' uno storage condiviso, quindi forse e' un
buon compromesso!
>
In questo caso si, a parte la fase di avvio del sistema operativo, i dischi
locali non li andrai ad usare.

Per curiosità, cosa userai come storage condiviso ?
Marco Ciampa
2014-01-05 14:13:12 UTC
Permalink
On Sat, Jan 04, 2014 at 02:34:40PM +0100, Nicola Ferrari (#554252) wrote:
> Grazie Marco della risposta.
> Avevo visto il post.
>
> Visto che da quel che ho capito:
> - il b320i e' un fakeraid (controller software)
> - per attivare la parte RAID ho dovuto mettere nel bios una licenza
> apposita ed è quella che lo tiene attivo (e non mi piace)...
>
> Pensavo che, raid sw per raid sw, a questo punto tolgo tutta la
> configurazione del b320i licenza compresa, mi tengo le unità fisiche
> (cosi' si vedono, ho provato) e su quelle ci configuro md.
> Installo una debian7, partiziono con md/lvm seguendo il layout
> "standard" di pve, e poi la faccio diventare proxmox seguendo il
> wiki.
>
> Provo, vi faccio sapere, e in caso di successo posto il tutto!

Se hai bisogno di un consiglio, chiama. Il telefono te lo scrivo in privato.

PS: ora non serve più neanche avere una partizione di boot.
Con le ultime Debian puoi crearti il raid software (RAID1) e
installare LVM sopra di questo facendo il boot direttamente: grub2 "vede"
sia LVM che RAID1 e quindi funziona tutto configuarando LVM come per una
installazione di PROXMOX "standard".

bye

--


Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana
di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci
passi. Per quanto cammini, non la raggiungerò mai. A cosa serve
l'utopia? A questo: serve a camminare." Eduardo Galeano

+--------------------+
| Linux User #78271 |
| FSFE fellow #364 |
+--------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Nicola Ferrari (#554252)
2014-01-05 16:33:51 UTC
Permalink
On 01/05/2014 03:13 PM, Marco Ciampa wrote:>
> Se hai bisogno di un consiglio, chiama. Il telefono te lo scrivo in privato.
>

Grazie!

> PS: ora non serve più neanche avere una partizione di boot.
> Con le ultime Debian puoi crearti il raid software (RAID1) e
> installare LVM sopra di questo facendo il boot direttamente: grub2 "vede"
> sia LVM che RAID1 e quindi funziona tutto configuarando LVM come per una
> installazione di PROXMOX "standard".
>

In realta' anche in una PVE3 standard c'e' la partizione sda1 con il
boot e la sda2 con sopra lvm...
Dici che basta creare un solo MD, sopra il quale metto direttamente LVM
e NON creo un lv per il boot ma lo lascio direttamente sotto la pve-root?

Provo!
Grazie!


--
+---------------------+
| Linux User #554252 |
+---------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Marco Ciampa
2014-01-05 18:11:19 UTC
Permalink
On Sun, Jan 05, 2014 at 05:33:51PM +0100, Nicola Ferrari (#554252) wrote:
> On 01/05/2014 03:13 PM, Marco Ciampa wrote:>
> >Se hai bisogno di un consiglio, chiama. Il telefono te lo scrivo in privato.
> >
>
> Grazie!
>
> >PS: ora non serve più neanche avere una partizione di boot.
> >Con le ultime Debian puoi crearti il raid software (RAID1) e
> >installare LVM sopra di questo facendo il boot direttamente: grub2 "vede"
> >sia LVM che RAID1 e quindi funziona tutto configuarando LVM come per una
> >installazione di PROXMOX "standard".
> >
>
> In realta' anche in una PVE3 standard c'e' la partizione sda1 con il
> boot e la sda2 con sopra lvm...
> Dici che basta creare un solo MD, sopra il quale metto direttamente
> LVM e NON creo un lv per il boot ma lo lascio direttamente sotto la
> pve-root?
>
> Provo!
> Grazie!

Io ce l'ho così e funziona...

--


Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana
di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci
passi. Per quanto cammini, non la raggiungerò mai. A cosa serve
l'utopia? A questo: serve a camminare." Eduardo Galeano

+--------------------+
| Linux User #78271 |
| FSFE fellow #364 |
+--------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Nicola Ferrari (#554252)
2014-01-09 17:50:31 UTC
Permalink
Per i 2 controller aggiuntivi dei due nodi mi hanno chiesto una cifra
notevole.. 700+iva x 2

Quindi preferirei riuscire a far funzionare quello integrato.
Il RAID con MDADM non c'e' verso di farlo andare.
Le ho provate tutte:

Se installo Debian e in fase di installazione costruisco il MD dal
partitoner, l'installazione e' lentissima... ma lenta lenta.. 4/5 ore
per completarsi.

Se installo PVE sul primo disco, e poi costruisco dopo il MD, ho *una
fila* di errori di I/O error quando costruisco i MD
mdadm --create --level=1 --raid-disks=2 missing /dev/sdb

Questo disabilitando il controller RAID e tenendo i dischi visibili come
normali SATA.

C'e' qualche test che posso fare, magari con una live, per vedere che i
dischi/controller non abbiano problemi per gli affari loro?

Inoltre...
HP fornisce il supporto per RHEL/Suse Enterprise.

RHEL 6.4 e anche SLE usano il kernel 2.6.32 ...

Posso in qualche modo compilare partendo da li' il modulo che manca per
farlo funzionare con Wheezy/PVE?

Anche il kernel PVE ho visto che sarebbe attualmente un 2.6.32 ma non ho
idea di come fare in fase di installazione a passare il modulo, perche'
non c'e' disponibile una console (o meglio si', ma vedo solo eco di quel
che succede, non noto la possibilita' di digitare comandi come sotto
l'installer di debian. Sbaglio?)

Avendo a disposizione il file .ko, posso metterlo da qualche parte
smanettando con initramfs per far si che sia "visto" dall'installer di
PVE? Non ho idea di come funzioni il gioco..

Avete qualche altro suggerimento?
Grazie mille!


--
+---------------------+
| Linux User #554252 |
+---------------------+
Diaolin
2014-01-10 07:08:52 UTC
Permalink
al boot di proxmox metti

hpsa_allow_any=1

tanto per iniziare e vediamo se vede lo smartarray
poi

segui la mail che allego

###################################

I see that current redhat kernel use 2.0.2 hpsa drivers

/lib/modules/2.6.32-11-pve/kernel/drivers/scsi# modinfo hpsa
filename: /lib/modules/2.6.32-11-pve/kernel/drivers/scsi/hpsa.ko
license: GPL
version: 2.0.2-3
description: Driver for HP Smart Array Controller version 2.0.2-3


Do you know what's new in version 3 ? new controllers model support ?


I have built the module myself and this fixes my issue with the snmp
storage agent.

filename: /lib/modules/2.6.32-11-pve/kernel/drivers/scsi/hpsa.ko
license: GPL
version: 3.0.0-2
description: Driver for HP Smart Array Controller version 3.0.0-2
author: Hewlett-Packard Company
srcversion: 6DEA5B23817C8664DACA304
alias: pci:v00000E11d*sv*sd*bc01sc04i*
alias: pci:v0000103Cd*sv*sd*bc01sc04i*
alias: pci:v0000103Cd0000333Fsv0000103Csd0000333Fbc*sc*i*
alias: pci:v0000103Cd0000323Bsv0000103Csd00003356bc*sc*i*
alias: pci:v0000103Cd0000323Bsv0000103Csd00003355bc*sc*i*
alias: pci:v0000103Cd0000323Bsv0000103Csd00003354bc*sc*i*
alias: pci:v0000103Cd0000323Bsv0000103Csd00003353bc*sc*i*
alias: pci:v0000103Cd0000323Bsv0000103Csd00003352bc*sc*i*
alias: pci:v0000103Cd0000323Bsv0000103Csd00003351bc*sc*i*
alias: pci:v0000103Cd0000323Bsv0000103Csd00003350bc*sc*i*
alias: pci:v0000103Cd0000323Asv0000103Csd00003233bc*sc*i*
alias: pci:v0000103Cd0000323Asv0000103Csd0000324Bbc*sc*i*
alias: pci:v0000103Cd0000323Asv0000103Csd0000324Abc*sc*i*
alias: pci:v0000103Cd0000323Asv0000103Csd00003249bc*sc*i*
alias: pci:v0000103Cd0000323Asv0000103Csd00003247bc*sc*i*
alias: pci:v0000103Cd0000323Asv0000103Csd00003245bc*sc*i*
alias: pci:v0000103Cd0000323Asv0000103Csd00003243bc*sc*i*
alias: pci:v0000103Cd0000323Asv0000103Csd00003241bc*sc*i*
depends:
vermagic: 2.6.32-11-pve SMP mod_unload modversions
parm: hpsa_allow_any:Allow hpsa driver to access unknown HP Smart Array
hardware (int)
parm: hpsa_simple_mode:Use 'simple mode' rather than 'performant mode'
(int)


This version supports more controllers and can also use the option
hpsa_allow_any which is not available in the default 2.0.2-3 version.

Steps to compile the new driver
git clone git://git.proxmox.com/git/pve-kernel-2.6.32.git
download the hpsa-3.00-2 driver from the cciss page on sourceforge
do a make all and wait until it starts to compile the kernel
then copy all the hpsa.c and h files from the package and copy them to
linux-2.6.32-11-pve/drivers/scsi/
then do again a make all and wait until the hpsa module gets compiled

(i get an error while building at the end because i'm building in a
chroot)

then copy the hpsa driver to the server and replace the existing hpsa
driver
next run:
depmod -ae 2.6.32-11-pve
and give an update to initramfs:
update-initramfs -k 2.6.32-11-pve -u

then reboot

Now the server is running with the updated 3.0.0-2 driver and the snmp
agents are working with this driver.

Would it be possible to get this driver as an update package or as a
standalone package for who needs it?

Regards,
William

---
S’à destacà l’ultima föia dal bósch nét
crodàda l’ei, solàgna, ‘n mèzz ai sàssi
e ‘ntant fis-ciava ‘n zìfol de oseleti
a tegnìr vìo ‘l pensér che vèn matìna
[Diaolin]
Antonio Galea
2014-01-16 16:08:56 UTC
Permalink
2014/1/16 Matteo Ragni <nirvana1289-***@public.gmane.org>:
>
> ecco qui si apre il problema che ho adesso. Il contenuto fisico del server mysql, lo vorrei spostare nell'LVM. Qualcuno ha mai
> provato a fare una cosa del genere?


http://bit.ly/1eUUYe0

:-)

Antonio
Matteo Ragni
2014-01-16 16:18:53 UTC
Permalink
> http://bit.ly/1eUUYe0
>
> :-)
>
> Antonio


Ma va? visto che la metà dei risultati sono errori per chi ha seguito
quelle guide, su una cosa delicata come un database vorrei un consiglio
diretto, se qualcuno ha da darlo, non una ricerca su stack exchange.

--
distinti saluti,

------------
Matteo Ragni
------------

<aka: nirvana1289> # reply to: nirvana1289-***@public.gmane.org
GPG Public Key: 0x0141EDBD238098A0 @ pgp.mit.edu
gpg --keyserver pgp.mit.edu --recv-key 0x0141EDBD238098A0
Antonio Galea
2014-01-17 09:11:39 UTC
Permalink
2014/1/16 Matteo Ragni <nirvana1289-***@public.gmane.org>:
>
> Ma va? visto che la metà dei risultati sono errori per chi ha seguito quelle guide, su una cosa delicata come un database vorrei un consiglio
> diretto, se qualcuno ha da darlo, non una ricerca su stack exchange.

I database non sono mica bestie esotiche, sono software come gli
altri. La prima risposta su StackExchange va benissimo.

Antonio
Francesco Gabriele
2014-01-17 13:41:45 UTC
Permalink
Grazie Marco,

ho capito xche non faceva il boot, ho dovuto disabilitare completamnete il
controller raid e poi ho fatto il raid software.

Dynamic Smart Array disabled. To disable: *Press F9 to boot into RBSU
*Navigate to System Options -> HP Dynamic Smart Array B320i and select
disable *Go to System options -> SATA Controller options and select Legacy
SATA or AHCI *Reboot the machine and now you will be able to install the OS.


----
Francesco Gabriele

Blog - www.ubuntuserver.it
Linux users #5484 Frank (IT)
Asterisk users #852 Frankies (IT)



Il giorno 17 gennaio 2014 10:11, Antonio Galea <antonio.galea-***@public.gmane.org> ha
scritto:

> 2014/1/16 Matteo Ragni <nirvana1289-***@public.gmane.org>:
> >
> > Ma va? visto che la metà dei risultati sono errori per chi ha seguito
> quelle guide, su una cosa delicata come un database vorrei un consiglio
> > diretto, se qualcuno ha da darlo, non una ricerca su stack exchange.
>
> I database non sono mica bestie esotiche, sono software come gli
> altri. La prima risposta su StackExchange va benissimo.
>
> Antonio
> --
> Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
> "subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
>
>
>
Marco Ciampa
2014-01-17 14:58:48 UTC
Permalink
On Fri, Jan 17, 2014 at 02:41:45PM +0100, Francesco Gabriele wrote:
> Grazie Marco,
>
> ho capito xche non faceva il boot, ho dovuto disabilitare completamnete il
> controller raid e poi ho fatto il raid software.
>
> Dynamic Smart Array disabled. To disable: *Press F9 to boot into RBSU
> *Navigate to System Options -> HP Dynamic Smart Array B320i and select
> disable *Go to System options -> SATA Controller options and select Legacy
> SATA or AHCI *Reboot the machine and now you will be able to install the OS.

Adesso mi torna! Felice per te!

--


Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino di due passi, lei si allontana
di due passi. Faccio dieci passi e l'orizzonte si allontana di dieci
passi. Per quanto cammini, non la raggiungerò mai. A cosa serve
l'utopia? A questo: serve a camminare." Eduardo Galeano

+--------------------+
| Linux User #78271 |
| FSFE fellow #364 |
+--------------------+

--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request-***@public.gmane.org
Continue reading on narkive:
Loading...