Newsgroup: it.comp.os.linux.sys
Titolo: Flame: raid HW o SW?

Vediamo di generare un bel flame.
 
Oggigiorno (Settembre 2016), considerata la potenza dei server attuali, quali possono essere i vantaggi di un raid HW rispetto ad uno SW?
 
Io non vedo alcun vantaggio. 
 
Una volta, qualche anno fa, le performance erano migliori in quanto il sistema non si doveva occupare del raid essendo gestito dalla controller, ma con le macchine odierne, spesso biprocessori (scopro solo ora che siamo arrivati a 18 core!), con decine di giga di ram, in che modo una stupidissima controller con CPU spesso PowerPC da pochi gigaherz e 2GB di cache, può essere più performante di un server biprocessore a 18 core con hyperthreading (quindi 72 thread in totale) con magari 64GB di ram ? Ma anche rispetto ad un ben più economico biprocessore esacore con 64GB (server standard qui da me per i nuovi acquisti)
 
L'unico vantaggio è forse la NVcache, non presente su raid sw. 
Il writeback, lo fa già Linux di suo, volendo.

 Oggigiorno (Settembre 2016), considerata la potenza dei server attuali, quali possono essere i vantaggi di un raid HW rispetto ad uno SW?
 
in ogni caso tu vuoi usare ZFS, quindi te ne fotti del RAID HW :P
 
Ciao Jack

 in ogni caso tu vuoi usare ZFS, quindi te ne fotti del RAID HW :P
 
No, non voglio, finchè non viene integrato nel kernel.
Ma anche se volessi, quali sarebbero i vantaggi di un raid gestito da ZFS rispetto ad uno software?
 
Il problema è che alcuni prodotti (XenServer in primis) non supportanto il raid software e questo mi rompe a dir poco gli zebedei. Essere costretti ad usare un raid hardware quando oggigiorno le "performance inferiori" del software sono pressochè nulle a fronte di infinite possibilità extra date da mdadm

 Ma anche se volessi, quali sarebbero i vantaggi di un raid gestito da ZFS rispetto ad uno software?
 
era una battuta, volevo aggiungere flame al flame :)
 
I vantaggi sono i vantaggi che ZFS ha rispetto a tutto il resto :)
 
Ciao Jack

 quali possono essere i vantaggi di un raid HW rispetto ad uno SW?
 
Ad esempio che, su un raid hardware con dischi hot-swap non serve nessun 
sistemista che dia comandi di sistema ma una qualsiasi scimmia ammaestrata 
sfila il disco guasto e infila il nuovo disco.
 
Ad esempio che non ci si deve preoccupare/gestire se il disco che si rompe è 
quello di boot.
 
Ad esempio che il controller può attivare immediatamente un eventuale disco 
spare (ok, non so se questo viene gestito automaticamente anche dal raid sw)
 
-- 
Stefano L.

 spare (ok, non so se questo viene gestito automaticamente anche dal raid sw)
 
Gli hotspare ci sono nel raid sw da sempre. Basta che aggiungi il disco all'array  (--add) e lui lo stessa come spare. In seguito volendo puoi metterlo in funzione a mano facendo il grow.
 
comunque sia, sono tutti e 3 punti che si risolvono con adeguata istruzione delle scimmie che dovranno gestire il tutto. (sempre che non siano problematiche risolvibili a livello di configurazione, l'ultima sicuramente si, la seconda quasi sicuramente, la prima bisognerebbe provare)
 
Domande: 
1) ma se invece di creare il raid su una partizione lo creo su tutto il disco mediante raw-devices (md0 che punta a /dev/sda e non /dev/sda1) in teoria lui replica anche l'MBR e quindi non serve replicare grub
 
2) ma se invece di installare grub dentro l'mbr lo installo nella partizione (come si faceva una volta con LILO, con grub non l'ho mai fatto), mdadm replica anche quello, in teoria.

 Una volta, qualche anno fa, le performance erano migliori in quanto il sistema non si doveva occupare del
raid essendo gestito dalla controller, ma con le macchine odierne, 
spesso biprocessori (scopro solo ora che
siamo arrivati a 18 core!), con decine di giga di ram, in che modo una 
stupidissima controller con CPU spesso
PowerPC da pochi gigaherz e 2GB di cache, può essere più performante di 
un server biprocessore a 18 core con
hyperthreading (quindi 72 thread in totale) con magari 64GB di ram ? Ma 
anche rispetto ad un ben più
economico biprocessore esacore con 64GB (server standard qui da me per i 
nuovi acquisti)
 
 
Sei davvero sicuro che le performance possano essere anche solo 
paragonabili? Io non ho mai avuto performance tali da farmi stare 
tranquillo con raid software, nemmeno su macchine di tutto rispetto.
 
Il problema dei RAID è che le performance ti servono proprio quando il 
sistema va in sofferenza, non quando a macchina scarica dai un hdparm 
-tT. Ed avere un hardware che fa solo questo e si occupa della parte I/O 
mentre tu hai la macchina in hang o fortemente sotto carico, fa la 
differenza tra mandarla definitivamente in crisi o tenerla ad un livello 
accettabile di performance.
 
Per quanto mi riguarda, preferisco spendere 450 euro su un server da 
6.000, ma avere una macchina con un controller raid hardware con la sua 
cache, non intaccabile da eventi esterni e che mi continua a funzionare 
anche se l'OS si è ubriacato.
 
Ma è una mia opinione.

 Ma è una mia opinione.
 
e questo prescinde dal fatto che vmware non supporta raid software o 
fake raid e che ormai server senza vmware praticamente non ne vedo più 
da svariati mesi (anche mono macchina ha i suoi vantaggi, tra cui la 
facilità di effettuare i backup).

 ram ? 
 
Hai più banda passante tra cpu e disco (che ha senso solo in alcuni contesti)
 
 
Enrico

 quello di boot.
 
Di questo, a meno che tu non abbia fatto le cose ad minchiam, non te ne
preoccupi nemmeno su di un RAID software
 
Enrico


Premessa: non per amor di flame ma per scarsa esperienza di raid sw.
 
Il punto è che devi fare e puoi sbagliare/dimenticare e poi,
qualunque macchina è sempre in grado di capire che il primo disco è andato a 
donnine per cui deve fare il boot dal secondo disco ?
 
E poi, se voglio fare raid-5 come la metto per il boot ?
 
-- 
Stefano L.

 anche se l'OS si è ubriacato.
 
Il raid hardware ha i suoi vantaggi, questo è innegabile.
Ma ha anche dei *grossi* svantaggi, e personalmente reputo questi svantaggi talmente grossi da far passare in secondo piano i vantaggi. Ne elenco alcuni:
 
1) ZERO flessibilità. In pratica decide la controller cosa dovrai configurare e come, non te.
 
2) Tutto ruota attorno alla controller, se la controller si frigge, sei fottuto 9 volte su 10. Se la controller impazzisce ed inizia a corrompere dati nel raid, sei fottuto 9 volte su 10. Da questo punto di vista il raid software è di qualche ordine di grandezza più affidabile. costantemente aggiornato con il kernel e seguito dagli sviluppatori del kernel (che non sono proprio gli ultimi arrivati) a differenza di un firmware della controller aggiornato ogni morte di papa da non si sa chi.
 
3) se ti va in vacca l'intero sistema, devi spostare i dischi in un sistema analogo con la stessa identica controller. Questo non sempre è possibile, sopratutto su hardware vecchio e quasi nessun vendor ti supporta il cambio di controller saltandone più di 1 generazione. Quindi (io uso DELL) in un server del 2010, DELL non supporta la migrazione dei dischi ad uno del 2016 perchè ci sono 3 generazioni di controller in mezzo. A meno che uno non abbia una vorticosa rotazione di hardware, saltare 3-4-5 generazioni di controller potrebbe essere la normalità. Non tutti cambiano l'intero parco macchine ogni 5-6 anni. Con il raid sw se ti va in vacca il sistema, prendi un muletto simile (nemmeno identico a quello di origine), sposti i dischi, accendi e vai. 
Soluzione ufficiale DELL? backup+restore tra le macchine. (siamo seri, non diciamo cazzate, dai)
 
4) se hai sistemi RAID-1 software, puoi fare il replace di un disco in maniera preventiva senza mai perdere la ridondanza, cosa impossibile con un raid hw.
Ad esempio anzichè rimuovere il disco e sostituirlo con un altro come si farebbe in un raid hw (durante tutto il resync perdi la ridondanza), aggiungi il terzo disco, converti il raid a 3, togli il disco vecchio, riduci il raid a 2. In tutta la fase non hai mai perso ridondanza, nemmeno per 1 secondo. Se hai dischi vecchi di anni e vuoi farne una sostituzione preventiva, questo è un vantaggio, dato che durante il resync di un disco, l'altro, vetusto, potrebbe saltar per aria. Con un raid hw se fai la stessa cosa e murphy ti osserva, sei fottuto. Cambi un disco "funzionante" e l'altro muore. (a me è capitato in un RAID10 hardware proprio di recente)

 preoccupi nemmeno su di un RAID software
 
Io ho il mio metodo, ovvero installare grub su tutti i dischi.
Te come fai? Vediamo se ci sono metodi migliori (o se il mio è semplicemente sbagliato)

 E poi, se voglio fare raid-5 come la metto per il boot ?
 
Da grub2 dovrebbe essere fattibile.
Comunque sia, rendiamo il flame più utile e concreto: ho con me un DELL R510 con 3 dischi, in attesa di una controller prima di inserirlo in produzione. 
 
Nel frattempo posso fare alcune prove, se volete fare qualche test, ditemi pure, intanto faccio questo:
 
- installo debian in stile windows (avanti-avanti-avanti)
- singolo volume raid5 a 3 dischi (software ovviamente)
- singolo volume LVM sopra il raid5
- tutto il sistema "sfuso" dentro l'LVM sopra il RAID5
 
vediamo se fa il boot.
Torno fra poco.


Guarda, in linea di massima sono d'accordo con te, ma non potendolo 
utilizzare sotto vmware, per me il raid software è come se non esistesse 
purtroppo, salvo qualche NAS per i backup (che però hanno altre priorità 
e altre prerogative).

 Da grub2 dovrebbe essere fattibile.
 
Ho installato ieri una Ubuntu server 16.04.1 su un RAID, e durante il 
partizionamento ha ancora l'avviso che /boot deve stare su un RAID-1 e 
non può stare su un RAID-5.
 
Non ho fatto prove per vedere se è vero, e ho fatto una partizione 
RAID-1 da 32GB sui 4 dischi.
 
Anche io ho sempre installato grub su tutti i dischi nel caso salti il 
primo.
 
Bye.
 
 

 e altre prerogative).
 
Io sono nella tua stessa situazione e sinceramente trovo inconcepibile che sia VMWare che Citrix si ostinino a non supportare raid-sw. Basterebbe supportarlo senza dare alcuna garanzia o assistenza.

 non può stare su un RAID-5.
 
Mai usato ubuntu server, ma ho installato proprio ora una Debian 8.2
senza alcuna personalizzazione (avanti-avanti-avanti), ho creato 1 raid-5
e sopra di esso un volume lvm.
 
Fa il boot correttamente senza batter ciglio.
Ok, in  realtà una personalizzazione l'ho fatta, per disattivare l'uso degli UUID
in fase di boot, che a me non funziona mai. Mantenendo attivo l'UUID, grub non
rileva il disco e salta per aria. Ammetto che potrei aver sbagliato io in fase di
installazione, debian fa installare grub su un solo disco, poi esce. Volendolo
installare su tutti i dischi, ho aperto la shell, montato il sistema appena installato, montato in bind la /dev/ dentro la /mnt/dev e installato grub sui dischi restanti e secondo me è questa fase che ha spaccato tutto.
 
riavvio in recovery, disattivo gli UUID, reinstallo grub su tutti i dischi e fa il boot perfettamente da un RAID-5 software.

 Io sono nella tua stessa situazione e sinceramente trovo inconcepibile che sia VMWare che Citrix si ostinino a non supportare raid-sw. Basterebbe supportarlo senza dare alcuna garanzia o assistenza.
 
Imho non può permetterlo perchè significherebbe caricare la sua busybox di un 
lavoro ulteriore (in qualche caso anche molto pesante da gestire - immaginiamo 
vecchi dischi su cui un operatore sadico o ignorante va a creare diversi RAID6) 
e far perdere reattività all'intero sistema, venendo così additati come "sistema 
non performante".
 
Ovviamente è il mio parere senza alcuna conferma
Rizio
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

 non performante".
 
Non conosco VMWare, non pensavo avesse una semplice busybox ma un vero e proprio sistema preinstallato tipo XenServer

 Non conosco VMWare, non pensavo avesse una semplice busybox ma un vero e proprio sistema preinstallato tipo XenServer
 
La mia esperienza è che, se non erro dalla 4 in poi (non ricordo esattamente), 
hanno eliminato il sistema linux che usavano come core su cui far girare il loro 
kernel e i loro servizi a fronte di una busybox più essenziale, addirittura 
nella 5 (direi) l'accesso alla console era deprecato e sconsigliato dalla stessa 
vmware. Dalla 6 mi sembra che le cose siano tornate leggermente indietro però il 
sottosistema è rimasto molto essenziale: pochi comandi posix e molto hardening 
vmware con comandi specifici e impostazioni proprietarie.
 
Poi considera che non sono mai andato a guardare nel dettaglio cosa ci fosse di 
"comune" nella cli e fino a che punto fosse standard, mi sono sempre 
accontentato di usare quello che serviva ma nelle diverse versioni ho notato 
questo sviluppo di architettura


 Fa il boot correttamente senza batter ciglio.
 
Piccolo test: rimosso brutalmente il disco principale dal RAID-5, mdadm ovviamente se ne è accorto è l'ha buttato fuori dal raid.
Riavvio con il disco rimosso, parte senza fare storie anche con raid degradato (in rete si trovano pareri discordati)
 
Riavviato, inserisco il disco e con un semplice
 
mdadm --add /dev/md0 /dev/sda1
 
il disco viene reinserito ed il rebuild avviato automaticamente.
 
Adesso provo a:
1) configurare mdadm.cnf per reinserire automaticamente il disco senza intervento umano
 
2) reinstallare grub al cambio di status da degradato a online
 
vediamo che succede..... torno tra un po.

 2) reinstallare grub al cambio di status da degradato a online
 
Questo è facile, basta specificare "PROGRAM" ed uno script da eseguire ad ogni cambio di status. Tale script dovrà semplicemente reinstallare grub sul disco appena inserito (il disco in questione è uno degli argomenti che mdadm passa allo script)

 si trovano pareri discordati)
 
Quello che intendevo io è che se il primo disco si guasta ma non c'è nessuno 
che lo rimuove, il bios della macchina è sempre in grado di capirlo e 
passare al secondo disco o puo' ostinarsi a tentare il boot da un disco che 
non funziona ?

 non funziona ?
 
Dipende dal bios, credo.
Avendo dischi 'liberi' e non sotto array, quasi tutti i bios permettono di settare una boot-list, se hai 3 dischi, li metterai tutti e 3 in successione.
 
se usi una controller (senza volume raid ma dischi "sfusi"), invece, molto probabilmente ci pensa la controller a far fare il boot da 1 dei dischi qualunque, dato che il bios vede, come boot device, la controller e non i singoli dischi (almeno in questo server)

 Lui riaggiunge un disco solo se identifica i metadati compatibili con l'array.
 
In realtà si può fare, ma non sono capace io.
Da mdadm.conf, sezione POLICY:
 
spare-same-slot
  as above and additionally if given slot was used by an array that went degraded   
  recently and the device plugged in has no metadata then it will be 
  automatically added to that array (or it's container)
 
da quel che leggo, se il disco viene reinserito nello stesso slot [1] e non contiene metadati, lui lo aggiunge automaticamente al raid.
 
Nella stessa sezione indica di eseguire un "mdadm --udev-rules" per aggiornare le regole di udev.
 
Ora, io ho sia aggiornato le regole di udev, sia configurato il "spare-same-slot", rimosso i metadati dal disco, ma non funziona nulla.
 
udev non fa altro che richiamare
 
"mdadm --incremental /percorso_al_nuovo_disco"
 
ma eseguendolo a mano, mdadm rifiuta il comando dicendo che manca "--run"
Aggiungendo "--run", mdadm non fa nulla perchè non trova i metadati sul disco.
 
Qualche idea ?
 
[1] in caso di SAS/SATA, come fa a ricordarsi lo slot usato, dato che quando estraggo/rimuovo i dischi il nome del device cambia ? Ho rimosso /dev/sda e quando l'ho reinserito me l'ha nominato /dev/sdd


... dipende ... credo ... probabilmente ...
 
Appunto, personalmente preferisco non dover provare, configurare, testare 
ecc.
 
Preferisco una buona scheda hardware che fa tutto da sola.
 
 
 
-- 
Stefano L.

 La mia esperienza è che, se non erro dalla 4 in poi (non ricordo...
 
Momento.
 
Premesso che:
- se ho un'installazione con almeno 2 nodi, non ho dischi locali se non 
per farci giare solo esx, quindi il problema non si pone (immagino avrò 
uno storage in iscsi, NFS o FC, e li posso anche metterci un raid 
software tanto al sistema è trasparente)
- anche se fosse, se pago 800 euro di support 1 anno su una banale ess+ 
non mi andrebbe bene la risposta "eh ma il raid sw non è supportato"
 
sarebbe comunque a mio avviso troppo limitante utilizzare un raid 
software in un ambiente virtuale, dove il collo di bottiglia è 9 volte 
su 10 il RAID e la cache del controller è più preziosa dell'aria che si 
respira...

 Preferisco una buona scheda hardware che fa tutto da sola.
 
Sono allineato. Preferisco spenderci di RAID che di benzina ad andare a 
risolvere problemi estremamente delicati come quelli sui dischi.
 
Oltretutto, nessuno ha parlato della lucetta ambra. Puoi configurare 
tutti gli alert che vuoi, ma la lucetta ambra sul disco ti serve sempre. 
Anche perchè poi non è banale capire che disco è saltato nell'array con 
un raid software. Non sottovalutate questo aspetto, la maggior parte 
delle volte quando si rompe un disco ci si affida alla signorina che 
prende le telefonate per far scollegare il disco rotto e far ricollegare 
quello nuovo, non a Kevin Mitnick.
 

 ecc.
 
Il server dovrai prima o poi accenderlo per configurarlo, oppure fa tutto da solo telepaticamente ?
 
Nel momento in cui lo accendi, guardi cosa ti dice il bios ed il gioco è fatto.
 
TUTTI i computer, almeno negli ultimi 15 anni, permettono il boot ciclico da uno o più device (tra cui i dischi). Sicuramente anche il tuo server lo fa, lo fa il mio desktop di casa da meno di 500 euro. Posso persino indicare l'ordine dei dischi, pensa un po.

 quello nuovo, non a Kevin Mitnick.
 
Cosa centra la lucina con il raid software ?
 
Comunque, non fraintendetemi, non sto dicendo che il raid sofware è meglio sempre e comunque, semplicemente mentre qualche anno fa il raid hw era meglio 8 volte su 10, secondo me ora, nel 2016, il sw potrebbe essere migliore 8 volte su 10.
 
Poi in ambienti virtualizzati, raid hw, ci mancherebbe (che ho anche io)
 
Ma se devi fare dei piccoli server con magari raid-1, IMHO, il raid-hw non ha alcun senso.

 hardware proprio di recente)
 
Va bene, ma davvero è una cosa che si fa, in quali ambienti ?
Senza contare che, visto che chiami in causa murphy, se in quella
fase sbagli un comando ..... :-P
 
-- 
Stefano L.

 ha alcun senso.
 
Ok, se il cliente proprio vuole risparmiare ci sta.
 
Rimane da verificare l'effettivo risparmio quando, a disco rotto, dovrà 
pagare l'intervento del sistemista per la sostituzione.
 
-- 
Stefano L.

 fase sbagli un comando ..... :-P
 
Anche in caso di raid hardware: se sbagli il comando mandi offline l'array....

 pagare l'intervento del sistemista per la sostituzione.
 
Nel mio caso il cliente e sistemista sono io.

 l'array....
 
Mai dato comandi, sfili il disco guasto, infili il disco nuovo.
 
-- 
Stefano L.

 HP, se non ricordo male, smart array 420
 
Interessante, questa ad esempio supporta RAID-1 a 3 dischi.
E poi c'è scritto che il formato dei dati è compatibile tra tutte le generazioni di controller SmartArray, nuove e vecchie. Questo semplifica la migrazione dei dischi.
 
Si sa che chip usa? E' proprietaria o rimarchiata ?

 Si sa che chip usa? E' proprietaria o rimarchiata ?
 
Francamente non lo so, non me ne sono mai preoccupato.
 
Credo però che sia tutta farina del sacco HP anche perché nelle ultime
generazioni dei server tutto il sw di gestione della scheda è integrato nel 
firmware del server.
 
A parte quello, sul sito HP c'è il repository Debian con i pacchetti per 
monitorare e riconfigurare on line controller array dischi ecc.
Una pacchia !
 
-- 
Stefano L.

 Una pacchia !
 
Hai un link per favore ?

 semplicemente sbagliato)
 
Il metodo è quello, per cose "ad minchiam" intendevo proprio il non
installare GRUB su tutti i dischi :)
 
Enrico

Questa non l'ho capita, alla controller (ma è maschile o femminile ?)
 
Io l'ho sempre usato al maschile, come tutte le parole in "-er".
 
Altrimenti dovrebbe finire in "-ess" "-trix" etc.
 
 
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

 Io l'ho sempre usato al maschile, come tutte le parole in "-er".
 
Io anche al maschile, non per un fatto di desinenza ma di equivalente 
italiano dell'anglicisimo; non so se sia una regola corretta (o se sia 
affatto una regola) ma mi viene naturale cosě.
 
Nei controlli automatici -e mi pare anche nei sistemi operativi ma non 
saprei dire esattamente il contesto- si usa il termine "controllore" 
per cui per me č sempre stato "il controller".
 
 
-- 
Andrea
 

 affatto una regola) ma mi viene naturale così.
 
Neutro e senza plurale, essendo un termine preso da una lingua straniera.
 

affatto una regola) ma mi viene naturale così.
 
Sì, in genere l'equivalente italiano è decisivo... anche nella
pronuncia di acronimi e sigle si fa riferimento alla versione
scomposta e tradotta. "La CPU" da "unità", "la RAM" da "memoria".


 Hai un link per favore ?
 
https://wiki.debian.org/HP/ProLiant#HP_Repository
 
 
Ad esempio nel sources.list metti:
 
deb 
http://downloads.linux.hpe.com/SDR/repo/mcp
 jessie/current non-free
 
 
-- 
Stefano L.

 andrebbe bene la risposta "eh ma il raid sw non è supportato"
 
Ehh, però attualmente è così: su esx non è supportato il raid sw (da quello che 
ricordo per lo meno)
 
 
Rizio
 
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

 più affidabile.
 
Nì. Per capirci, nella documentazione ufficiale di Sun, si consiglia di usare
ZFS con memorie ECC, in quanto altrimenti non hai sicurezza sul dato che vai
a scrivere
 
Enrico

 a scrivere
 
Per lo scrubbing a protezione dal bitrot?
Ok, questo è vero, ma a quanti è mai capitato di ritrovarsi con dati corrotti usando hardware enterprise?
 
Lo stesso problema, comunque, lo avresti anche su raid hardware quindi non cambierebbe nulla da questo punto di vista. AFAIK tutti i raid hw periodicamente leggono l'intero array alla ricerca di errori di lettura (ritornati dal disco), nessuno fa lo scrubbing logico del file. Se il disco ritorna '1', quando il realtà ci sarebbe uno '0', al raid hardware non frega una cippa, per lui il disco funziona

 Lo stesso problema, comunque, lo avresti anche su raid hardware quindi non cambierebbe nulla da questo punto di vista. AFAIK tutti i raid hw periodicamente leggono l'intero array alla ricerca di errori di lettura (ritornati dal disco), nessuno fa lo scrubbing logico del file. Se il disco ritorna '1', quando il realtà ci sarebbe uno '0', al raid hardware non frega una cippa, per lui il disco funziona
 
Si e no, piu` si che no.
Solo che il RAID SW usa in maniera piu` estesa la
RAM, per cui e` piu` soggetto a bit flip di questa.
 
Il discorso dello scrubbing del RAID non c'entra,
non e` una questioni di dati su disco, ma di dati
in transito da / per lo storage.
 
bye,
 
-- 
 
piergiorgio

 in transito da / per lo storage.
 
Si, ma se il dato in RAM è protetto da ECC, l'unico che può 'corromperlo' a quel punto è il disco.

 Si, ma se il dato in RAM è protetto da ECC, l'unico che può 'corromperlo' a quel punto è il disco.
 
Appunto "se" e` protetto da ECC.
 
Ma come scrivevo prima, il RAID SW usa molto
di piu` la RAM di un RAID HW, quindi diventa
sicuramente piu` importante usare ECC.
 
bye,
 
-- 
 
piergiorgio

 Io non vedo alcun vantaggio. 
 
http://xkcd.com/1737/
 
 
Ciao Jack

 
http://xkcd.com/1737/
 
 
Che si rifà a 
https://xkcd.com/378/
 
 
Enrico

 in ogni caso tu vuoi usare ZFS, quindi te ne fotti del RAID HW :P
 
Parlando seriamente (il "flame" in oggetto è ovviamente ironico), ZFS è una figata pazzesca. Non ho ancora avuto modo di usarlo, ma sto leggendo varia documentazione.
 
Quindi vario leggermente l'argomento:
 
raid HW or raid ZFS ?
 
I vantaggi di ZFS sono *infiniti* rispetto ad un RAID hardware (a parte la, secondo me cazzata, di non poter aggiungere dischi ad un RAIDZ) e ZFS da il meglio di se potendo gestire interamente i dischi, senza altre controller sotto di lui.
 
Su grossi array, un RAID-Z3 potrebbe salvarti il fondoschiena e non conosco nessuna controller che supporta il RAID-7
 
Per non parlare del fatto che ZFS sincronizza solo i dati, non i blocchi vuoti, come farebbe una qualunque controller. Su un array da 12TB (come i miei server di backup), dove lo spazio occupato è mediamente 4-5TB [1], poter risincronizzare solo quelli e non tutti e 12 i TB, dimezza i tempi di rebuild
 
Per le performance, sinceramente, non ho ancora trovato benchmark che rapportino un RAID-HW con mdadm e RAIDZ.
Sono più che convinto che con le CPU e RAM attuali presenti sui server, non ci sia alcun decremento prestazionale. 1 singolo core di uno Xeon moderno è $NumeroMoltoGrande più performante di una qualunque controller XOR PowerPC
 
Se mi date qualche dritta (o se volete eseguire qualche comando particolare) posso fare una comparazione. Ho un server con 8 dischi SAS 15k e RAID HW, posso provare ad installare tutto sul raid6 hw e fare dei test, poi piallo e metto ZFS in RAIDZ-2, stessi test, poi mdadm in raid6, stessi test.
 
 
[1] perchè un array da 12TB se ne uso solo 4? Perchè ho delle procedure che comprimono i backup obsoleti. I 12TB mi servono come "spool", poi terminati i backup, i vecchi vengono compressi.


Su ZFS puoi attivare la compressione _per_ dataset. In genere conviene,
ma usa un po' piu' la CPU (e' l'lz4 per default).
Anche la deduplica, che per un backup potrebbe essere interessante, ma
servono vagonate di RAM.
 
Ciao Jack
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

 ZFS è una figata pazzesca.
 
Occhio che non è tutto oro quello che luccica.
 
1) Un file system COW necessita di non essere mai riempito al 100%, ovvero
tieni sempre dello spazio libero alla fine del disco altrimenti rischi di
non poter più usare l'array.
 
2) ZFS ha delle performance leggermente inferiori ai file system tradizionali,
anche a causa del suo essere COW. Puoi mitigare con una o più SSD da usare
come cache, per ZIL e L2ARC (rispettivamente, cache in scrittura e cache in
lettura).
 
3) ZFS richiede molta RAM, sia per le operazioni normali (tende a fare caching
in maniera aggressiva), sia per la deduplica.
 
4) Ti consiglio di usare FreeBSD, non foss'altro perché potresti trovarti in
situazioni spiacevoli con il driver in Linux (nulla di rischioso per i dati,
ma tante bestemmie).
 
Se vuoi fare dei test, Bonnie++ potrebbe essere una soluzione (anche se su
Phoronix dovresti trovarne di già fatti)
 
Enrico

 Phoronix dovresti trovarne di già fatti)
 
Quelli che ho trovato comparavano un raid-5 hardware (senza dire quale hardware) ad un raid-5 zfs senza indicare dischi e configurazioni
 
In pratica come dire: quella macchina la è più veloce di questa qua.

 Del tipo?
 
Del tipo che le prestazioni sono un po' meglio (anche se la differenza è
minima) e soprattutto non hai problemi di compatibilità del modulo con il
kernel (per capirci, la versione 0.6.5.7 non supportava i kernel 4.7, con la
conseguenza che il boot non ti faceva vedere il pool ZFS). Sostanzialmente
sono questi gli unici motivi per cui ti ho dato quel consiglio
 
Enrico

 come funzionano i ZVOL, ovvero se disabilitano COW, ma non è quello che vuoi).
 
Ricordavo che COW fosse una delle idee alla base del progetto e pensavo 
nemmeno che disabilitarlo fosse possibile (e poi ti perdi gli snapshot 
gratuiti), dici che sugli ZVOL è possibile perché mappano un block 
device?
 
 
-- 
Andrea
 

 device?
 
Non dico. Penso. Nel senso che a naso potrebbe essere così, ma di fatto non lo
so
 
Enrico

 varia documentazione.
]zac[
 
Se vuoi c'e' anche btrfs che e' nativo in molte delle distribuzioni recenti 
e relativamente stabile.
 
Cosi puoi sperimentare un filesystem COW senza dovere aggiungere parti 
esterne.
 
 
P.S.
Lo uso da mesi su un pc personale (e' il filesystem principale e su SSD 
(boot su un'altra partizione, swap su altri dischi)) e non ha mai dato 
problemi. 
Comunque mi e' sembrato prudente avere anche gli snapshop di ogni settimana 
che sono inviati su due dischi differenti (e sto pensando di farlo anche su 
due pc differenti)).
 

 e relativamente stabile.
 
AHAHAHAHAH! No.
 
Enrico