Newsgroup: it.comp.os.linux.sys
Titolo: RAID6 o 10?

Assolutamente OT in questo gruppo, ma usenet è pressochè morta.....
 
Dovendo fare un server di backup, 8TB usabili circa, fareste un RAID6 o RAID10?
 
Io sarei per il RAID-6, come ho sempre fatto, ma è mostruosamente lento durante i rebuild. Fare rebuild di 8TB richiede alcuni giorni.
 
Un RAID10 richiederebbe poche ore, dovendo rebuildare solo 1 disco, ma è anche molto più insicuro. (puoi perdere solo 1 disco per coppia, nel 6 puoi perdere qualunque disco fino a 2)
 
Su server in produzione, sempre e solo RAID-6.
Su questo backup potrei azzardare un RAID1+LVM ma non saprei.......
 
Ad esempio a 4 dischi, lo spazio occupato è uguale: 4x4TB in RAID6 sono 8TB usabili, 4x4TB in RAID1+LVM sono sempre 8TB
Il primo però è molto più espandibile, mi basta aggiungere 1 disco, il secondo devo aggiungere a coppie. Il primo va ridimensionato l'array (richiede tempo), il secondo basta estendere LVM, immediato.

 estendere LVM, immediato.
 
Il ridimensionamento dell'array l'ho fatto una volta, è andato bene, ma non lo
rifarei nemmeno sotto tortura. Troppo rischioso
 
Enrico

 rifarei nemmeno sotto tortura. Troppo rischioso
 
Ti sto parlando di raid software. Sto abbandonando felicemente il raid hardware.
mdadm non ha mai fallito un reshape e nemmeno un grow (li faccio di routine,
mi permettono di partire con pochi dischi e cambiare forma quasi a piacere
in caso di necessità. In questo caso specifico, ad esempio, parto con 2
dischi e ne metto 3 il prossimo mese. Una semplice dilazione di pagamenti)
 
Ho fatto anche un grow con raid hardware. Concordo al 1000% con te: non lo
rifarò MAI più. Sopratutto quando la stupida controller ti scrive messaggi
tipo: "Initializing..." o frasi minacciose simili. mai, mai più.

 un bel RAID-1 a 3 dischi.
 
tra l'altro, il form-factor è interessante, mi permette di fare RAID1+LVM
con mirror a 3 vie, colonna per colonna :-)
 
A1 B1 C1 D1
A2 B2 C2 D2
A3 B3 C3 D3
 
dato che sul retro ho due SSD per il boot.
 
Calza a pennello, 4 mirror a 3 vie, incolonnati. Semplifica la manutenzione.

 dischi e ne metto 3 il prossimo mese. Una semplice dilazione di pagamenti)
 
Avresti una buona documentazione da consigliare?
 
In particolare dovrei (a medio termine) aumentare le dimensioni di un 
RAID-5 software con 4 dischi.
 
Non potendo aumentare il numero di dischi penso di dover cambiare un 
disco alla volta con dischi più capienti e ricostruire man mano, e alla 
fine fare il grow per usare lo spazio in più. Un HOWTO passo passo 
sarebbe il mio sogno. :D
 
Bye.

 Dovendo fare un server di backup, 8TB usabili circa, fareste un RAID6 o RAID10?
 
Che RAID-10?
Quello "standard" o quello "linux"?
 
bye,
 
-- 
 
piergiorgio


Beh, se cerchi con il tuo motore di ricerca
preferito ne trovi sacchi e sporte.
 
C'e` anche un linux-raid-wiki ufficiale...
 
bye,
 
-- 
 
piergiorgio

 botta di culo.
 
ti quoto alla grande.
uno dice: ma fra tutti i dischi si deve rompere proprio il disco gemello? 
la risposta è sì, mentre ricostruisce il raid proprio il disco gemello ha 
il top di probabilità di rompersi. 

 Quello "standard" o quello "linux"?
 
Quello Linux, non uso più hw raid nei nuovi server, non ha più senso IMHO.
Ma ammetto che mi prendi in contropiede, cosa cambia tra i due ?

 sarebbe il mio sogno. :D
 
Si, io farei uguale.
Cambi tutti i dischi, non fai il grow (presumo, altrimenti il disco
che devi usare come parità lui te lo usa come dati) e fai reshape.
 
Di documentazione su md ne trovi a chili, checchè se ne dica, è molto
più facile, intuitivo, sviluppato, testato, collaudato, ecc ecc di
qualunque altro sistema raid, sbagliare è veramente difficile.
 
E comunque, scrivi nella M/L linux-raid, sono molto attivi e ti rispondono.
 
OT, ma una cosa l'ho capita, almeno su kernel vecchi, MAI E POI MAI fare un
raid tra HDD e USB. Perdi dati. Scrive porcherie corrotte.
C'era una lunga e noiosa spiegazione, non me la ricordo e nemmeno mi
interessa, mi basta sapere che raid tra hdd e usb è un bel "no"
 

 il top di probabilità di rompersi.
 
Certo, assolutamente, vuoi perchè è più sollecitato, vuoi perchè Murphy è li
che osserva.
 
Poi parliamoci chiaro, la probabilità che si spacchi un secondo disco nel
medesimo mirror, con dischi nuovi, è bassissima, infatti io stesso quasi
sempre parto a 2 e poi cresco a 3 (anche a distanza di mesi), ma se hai
creato il mirror insieme, entrambi i dischi avranno lo stesso identico 
pattern di scrittura e di conseguenza lo stesso identico stress.
Mettici anche la stessa linea di produzione, se si spacca uno, la probabilità
che si spacchi anche l'altro gemello è tangibile, sopratutto su un rebuild
dove lo devi leggere tutto per intero. Sfasando di giorni/settimane/mesi
con un terzo disco, questa probabilità si riduce quasi a zero, dato che un
disco sarà più nuovo degli altri.
 
No, il raid che sta in piedi a botte di culo non mi piace. ho già perso più
volte dati con dei raid10. Preferisco spendere 300-400 euro in più e fare un
bel mirror a 3 o un RAID-6, che ritrovarmi a ripristinare terabyte di dati da
backup.
 
Tornando in tema: questo server di backup avrà dischi da 8TB, vai a
ripristinare 8TB di macchine virtuali, un fileserver etc etc, impieghi
settimane a rimettere in piedi tutto. Per risparmiare cosa, 300 euro scarsi ?


Scrivo sempre di "md", cioe` sw RAID.
 
Linux ha il "classico" 1+0 o 0+1,
ovvero un particolare RAID-10.
 
Per esempio, si puo` fare un RAID-10
con 3 dischi...
E se non erro si puo` scegliere se
avere, nell'esempio di cui sopra, 2
dischi di ridondanza, oppure 1.
 
bye,
 
-- 
 
piergiorgio

 dischi di ridondanza, oppure 1.
 
Si, questo lo so, ma non capisco cosa intendi tra raid "standard"
e raid "linux"
 
io sto parlando di "md"
 
comunque, sicuramente non sarà un RAID10, ma al limite RAID1+LVM
Ad inizio thread ho scritto RAID10 per semplificare, ma il risultato
è il medesimo.

 è il medesimo.
 
Non e` il medesimo.
 
Consideriamo il caso di 2 HDD, la cosa
si puo` estendere a piu` HDD.
 
Un RAID-1 ha la ridondanza di un HDD e la
velocita` in lettura e scrittura di 1 HDD.
 
Un RAID-10, sempre con 2 HDD, ha sempre
la stessa ridondanza, ma la velocita`
in letture di un RAID-0, cioe` 2 HDD.
In scrittura e` sempre 1.
Questo con layout f2, credo.
 
Secondariamente, LVM si puo` comunque
usare su qualunque RAID.
Quindi mi sfugge perche` un RAID-1+LVM
sia un'alternativa al RAID-10.
 
Il problema del RAID-10 e` che non e`
espandibile. Forse lo e` come numero
dischi, ma non come dimensione dischi.
 
Il RAID-6, invece, si puo` espandere
in tutte le direzioni.
 
bye,
 
-- 
 
piergiorgio

 dischi, ma non come dimensione dischi.
 
Lo è, devi cambiare entrambi i dischi del
mirror ed il RAID0 soprastante si adegua.
 
La differenza è che il RAID-6 si può espandere
1 disco alla volta (o mantenendone il numero, 
bisogna cambiarli tutti), il RAID10 si espande minimo
2 dischi alla volta (devi fare un mirror nuovo) o
cambiare entrambi i dischi di un mirror

 cambiare entrambi i dischi di un mirror
 
Il RAID-10 di linux non e` espandibile
in maniera cosi` semplice.
Perche` il layout non e` un 1+0, cioe` un
striping di mirror, ma e` un distribuzione
specifica di blocchi tra i vari dischi.
In questa distribuzione si puo` scegliere,
entro certi limiti, i dischi di ridondanza.
 
https://en.wikipedia.org/wiki/Linux_MD_RAID_10#Linux_MD_RAID_10
 
 
bye,
 
-- 
 
piergiorgio

 
https://en.wikipedia.org/wiki/Linux_MD_RAID_10#Linux_MD_RAID_10
 
 
non lo sapevo.
motivo in più per usare md a go-go, il mio odio viscerale per
hw raid aumenta a dismisura adesso.

 hw raid aumenta a dismisura adesso.
 
Diciamo che quel RAID-10 e` molto
interessante per certe configurazioni.
 
Il problema, come scritto prima, e`
che non e` flessibile.
 
bye,
 
-- 
 
piergiorgio

 E comunque, scrivi nella M/L linux-raid, sono molto attivi e ti rispondono.
 
Grazie, ora vedo.
 
Bye.

 più. :)
 
Si, ma per un "server", che magari
funziona 24/7, un RAID-5 e` pericoloso.
 
Quel 50% in piu` rischia di costarti
il 100% dei dati.
 
Bisogna, in questi casi, avere dei backup,
che pero` aumentano lo spazio necessario
da qualche altra parte...
 
E` chiaramente una questione di necessita`
e di strategie possibili.
 
Se il numero di dischi e` fisso a 4, se
il "server" e` accessibile solo tramite
connessione 1Gbit, allora punterei sul
RAID-6 usando dischi piu` grandi.
 
Varie ed eventuali...
 
bye,
 
-- 
 
piergiorgio

 Ti sto parlando di raid software.
 
Anche io. È proprio il concetto di reshape che mi fa paura, di fatto l'ho
adoperato per passare da un RAID10 software ad un RAID5 software perché non
avevo scelta, ma se posso evito volentieri ed estendo aggiungendo dischi (in
RAID software, ovviamente) e poi vado di LVM (facendo stripe se posso)
 
Enrico

 e raid "linux"
 
Intende questo:
 
https://en.wikipedia.org/wiki/Non-standard_RAID_levels#LINUX-MD-RAID-10
 
 
Enrico

 sempre e comunque un RAID-6.
 
RAID-10 standard ovvero quello classico, non modificabile,
fatto da una qualunque controller raid, ad esempio ?
 
Se si, concordo, infatti io uso sempre RAID-6
 
Se invece si parla di "md", non è così semplice la scelta.
Un rebuild di un RAID-6 rallenta all'aumentare dei dischi che
lo compongono. Il rebuild di 1 disco all'interno di un array
da 4 dischi richiede meno di un rebuild di pari dimensioni
ma all'interno di un array a 8 dischi. Non chiedermi perchè,
ho notato questa cosa su più e più controller e più e più server.
Inoltre, maggiore è la dimensione dell'array, maggiore è la probabilità
che si spacchino 2 o più dischi.
 
Un RAID-10 è trasparente alla dimensione dell'array, sotto ogni punto di vista.
Il rebuild durerà sempre uguale, che tu abbia 4 dischi o 400, sempre da 1 disco
gemello dovrai leggere (e solo da quello)
La probabilità che si spacchi un secondo disco all'interno del medesimo mirror
è la medesima, che tua stia usando 4 o 400 dischi, non cambia.
 
Quindi, costi a parte, un RAID10 "md" fatto con mirror a 3, è migliore sotto
ogni punto di vista rispetto ad un RAID-6. Chiaramente, costa molto di più.

 
https://en.wikipedia.org/wiki/Non-standard_RAID_levels#LINUX-MD-RAID-10
 
 
Si, era già stato linkato

 dei dati.
 
In realtà non cambia molto, il codice tra mdadm e LVM è praticamente condiviso
 
Enrico

 Hai informazioni diverse al riguardo?
 
Penso che la man page di md(4) da questo punto di vista sia esplicativa: RAID1
funziona come dici te. Facendo una ricerca ho però trovato come consiglio
quello di aggiungere --layout=f2 in fase di creazione dell'array, specificando
però che migliorerebbe le letture a scapito delle scritture. Personalmente non
l'ho provato, e non so se funziona (sempre la manpage, parla di far replica
solo su RAID10)
 
Enrico

 Si, era già stato linkato
 
Visto, colpa mia che non ho finito di leggere i post prima di rispondere ^^;
 
Enrico

 ogni punto di vista rispetto ad un RAID-6. Chiaramente, costa molto di più.
 
Nel caso di RAID-10 Linux, cioe` "md", cioe`
con la distribuzione dei blocchi "strana",
vi possono essere vantaggi, come gia` scritto.
 
Il problema e` che non si puo` fare un reshape
od un grow, a quanto pare.
Quindi una volta deciso il layout, quello resta.
 
bye,
 
-- 
 
piergiorgio


Il layout f2 (far 2) e` per il RAID-10
di "md", quello di cui si discuteva.
 
Lo uso sempre sui desktop, si ha un
mirror come ridondanza, ma in lettura
e` un RAID-0.
 
Il problema, come gia` scritto, e` che
non consente grow, ne` reshape.
 
Cambiare un HDD con uno piu` grande
necessita` creare un array nuovo.
 
Avendo LVM (o simili) potrebbe non
essere un grosso problema.
Si crea l'array nuovo e si fa un "pvmove".
In altri casi, non saprei...
 
bye,
 
-- 
 
piergiorgio

 Quindi una volta deciso il layout, quello resta.
 
Aspetta, forse ho capito le nostre incomprensioni.
 
Per me RAID10 e RAID1+0 sono sinonimi. Sono la stessa cosa.
Te invece fai riferimento a RAID1+0 come lo standard e RAID10 quello "strano" di md?

 Te invece fai riferimento a RAID1+0 come lo standard e RAID10 quello "strano" di md?
 
Eh, lo so, e` un po' un problema
di terminologia.
 
Di solito, comunemente, il RAID-10
e` il RAID 1+0.
 
Pero` Linux ha questo RAID-10 che e`
piu` "generico".
 
Quindi c'e` confusione fra i due casi.
 
Questo era il motivo della mia domanda
originale, proprio perche` il RAID-10
di Linux non e` la stessa cosa del
RAID 1+0, che pero` si chiama anche
RAID-10...
 
bye,
 
-- 
 
piergiorgio

 RAID-10...
 
Ma tra RAID10 "standard" fatto con MD ed un RAID1+0, fatto sempre con "md",
cambia qualcosa in termini di performance ?
Sicuramente il RAID10 crea un singolo device md0, poi ci pensa lui a sapere
come scriverci dentro, il RAID1+0 invece crea i singoli mirror ed un ulteriore
RAID0 a monte di essi.

 RAID0 a monte di essi.
 
Esatto.
 
Pero` credo, per esempio, un RAID-10 linux
con 4 HDD e layout near 2 sia equivalente
ad un RAID 1+0, ma e` un solo device mdX.
 
Ripeto, bisogna capire bene come sia il
layout, vi sono alcuni siti in giro che
cercano di spiegare la cosa.
 
bye,
 
-- 
 
piergiorgio

 cercano di spiegare la cosa.
 
Sto facendo prove su un near3, che dovrebbe essere standard
come layout, ma con mirror a 3 dischi invece che 2. Gli altri
layout sono troppo "strani", già il fatto che non capisco bene
come lavorano, è sufficeinte per non farmeli usare in produzione.
 
Il problema, però, è che l'output di "mdadm --detail md0" fatto su un
RAID10 n3 (o n2, cambia niente), non è esplicativo. Ho bisogno di sapere
quali dischi fanno parte di quali mirror. Può sembrare una banalità, ma
in caso di fretta, perchè magari bisogna rimpiazzare un disco, o in caso
di procedura di rimpiazzo avviata da me via cellulare in remoto (poi in
sede c'è qualcuno che fisicamente mi cambia il disco), avere il colpo
d'occhio è fondamentale.
 
Attualmente, non si capisce niente. "set-A", "set-B", è soggetto ad interpretazione.........
 
Vediamo che mi rispondono nella mailinglist ufficiale.
Ma se tra RAID1+0 e RAID10 non cambiasse nulla in termini di performance,
un RAID1+0 è più "leggibile" (senza contare il fatto che lo scrub sarebbe
in parallelo, impattando dischi mirror diversi, su un RAID10 mi pare sia
sequenziale)

 sequenziale)
 
Dipende dal layout!!!
 
Se non si ha chiaro in testa la differenza tra
far, near e offset, non si puo` ragionare su
come siano le prestazioni.
 
Il far e` quello consigliato, in questi casi.
 
bye,
 
-- 
 
piergiorgio

 Il far e` quello consigliato, in questi casi.
 
Non posso usare il far, il mio raid *DEVE* essere espandibile,
devo poter aggiungere o rimuovere dischi, il far è "vincolato".
 
Prendi l'output di un mdadm aggiornato, come quello riportato
sopra. Se ci fai caso, mostra il set relativo al disco.
Tale dicitura è soggetta ad interpretazione (nel man non mi pare
venga spiegata), può indicare ad esempio:
 
 
1- loop17 e loop22 sono in mirror tra loro, quindi non posso cambiarli
insieme
2- loop17 e loop22 sono su due mirror diversi, quindi li posso rimpiazzare
nello stesso momento.
 
Sono per la seconda ipotesi, visto che ho 3 set, pari al mio layout, quindi
se ho interpretato bene, loop17,loop18,loop19 sono in mirror, loop20,loop21,loop21 sono in un altro mirror.
 
Converrai con me che è una visualizzazione un pochino contorta. Sarebbe
stato più semplice qualcosa tipo set-1A, set-1B, set-1C, set-2A, set-2B etc etc
indicando ad esempio il numero di mirror (1, 2, ....) oltre al disco (A,B,C)
 
Un RAID1+0 ha una visualizzazione differente e molto più comprensibile:
 
$ cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md2 : active raid0 md1[1] md0[0]
      198656 blocks super 1.2 512k chunks
 
md1 : active raid1 loop22[2] loop21[1] loop20[0]
      101376 blocks super 1.2 [3/3] [UUU]
 
md0 : active raid1 loop19[2] loop18[1] loop17[0]
      101376 blocks super 1.2 [3/3] [UUU]
 
 
sai sempre cosa puoi togliere e quando, senza alcun dubbio o incertezza.
loop20,loop21,loop22 fanno parte dello stesso mirror.

 loop20,loop21,loop22 fanno parte dello stesso mirror.
 
Sicuramente, ma come scritto sopra, per prima
cosa non vedo la rilevanza e secondo, per il
RAID-10, bisogna capire il layout in ogni caso.
 
Da quello si arriva a vedere come siano
distribuiti i blocchi tra i vari dischi.
 
Tra l'altro, io sospetto, che se si
aggiunge un disco, ammesso sia possibile,
la distribuzione dei blocchi cambia.
 
bye,
 
-- 
 
piergiorgio

 Ma proprio tutti.
 
Si, questo lo faccio sempre.
Una delle cose che ho imparato è evitare di riempire gli slot
del server con i dischi. Piuttosto ne tengo qualcuno libero,
usando magari dischi più grossi, o prendo un server con più slot.
 
Prima o poi, ti salverà il deretano, è matematico.
 
 
O se no metto ZFS, che nonostante il mio odio viscerale verso di lui,
da questo punto di vista, è più affidabile, non bisogna preoccuparsi
di dati corrotti, di dischi che non vengono sbattuti fuori, di usare o
meno LVM sopra (lui integra un volume manager) etc etc etc

 meno LVM sopra (lui integra un volume manager) etc etc etc
 
Si, ZFS puo` essere una scelta.
Pare, pero`, non si possano aggiungere
dischi al RAID di ZFS.
Non so se le cose siano cambiate, nel
frattempo, ma era uno degli argomenti
di discussione fino a qualche epoca fa.
 
bye,
 
-- 
 
piergiorgio

 di discussione fino a qualche epoca fa.
 
Si può fare se sono mirror.
Non puoi variare in nessun modo un RAIDZ, invece.
 
Uno degli autori originali di ZFS ci stava lavorando (nella versione BSD),
l'aveva annunciato lo scorso anno o due anni fa, non ricordo. E'
sponsorizzato dalla
fondazione di FreeBSD
E' un lavoro ciclopico ma sarà implementato. Solo che essendo tutto
COW, porta via
tempo, sopratutto per fare reshape dei dati già esistenti (da quel che
lessi, in ZFS non
c'è nulla che possa riscrivere un blocco, fa solo append). Mi pare che
il codice per aggiungere
e rimuovere dischi, senza reshape dei dati esistenti, sia già stato
fatto da mesi ed è in alpha, è tutto
il resto che manca.
 
Il problema principale di ZFS, per quanto mi riguarda, a parte
l'impossibilità di estendere un RAIDZ che
io uso abitualmente su tutti i server tranne questo, è che non
perdona. Se sbagli, lui tira dritto e sei fregato.
In una macchina di prova ho aggiunto erroneamente un disco singolo ad
un RAID esistente anzichè aggiungerlo come
cache, lui l'ha fatto. Non c'è modo di rimuoverlo se non ricreando
tutto (con perdita di dati). In pratica un errore del
genere ti compromette l'intera ridondanza e l'unica soluzione è
sostanzialmente cancellare tutto.
 
Fallo su un array da 12TB (come la mia prova)..... ripristinalo te se
hai voglia :)

 hai voglia :)
 
Anche questo e` interessante, non sapevo,
pensavo fosse un piu` user friendly.
 
bye,
 
-- 
 
piergiorgio

 pensavo fosse un piu` user friendly.
 
Proprio ZERO.
Lo uso pochissimo, ma tutte le volte che devo aggiungere o rimpiazzare
un disco, devo leggere più documentazioni, proprio perchè non ammette
errori e non è che sia propriamente intuitivo come linea di comando.
(e non ammettendo errori, anche se fosse intuitivo, meglio leggere un
sito in più che uno in meno)

 di "md", quello di cui si discuteva.
 
Sì, lo so, l'ho detto anche tra parentesi ;)
Quello che dicevo è che, se non ho capito male, il tizio lo suggeriva anche per
il RAID1, al fine di migliorare le performance di lettura. Inoltre, sempre se
non ho capito male, Gandalf è più propenso a fare RAID1+LVM che RAID10, proprio
per la migliore espandibilità che ti permette questo layout. A questo punto
direi che un tentativo si può anche fare, alla peggio si cancella tutto e si
riparte (non a caso esistono gli ambienti di test ;) )
 
Enrico

 dischi al RAID di ZFS.
 
No, non si può. O meglio, non puoi fare il grow dell'array. Quello che puoi
fare è aggiungere un altro array al pool o cambiare i dischi
 
Enrico

 Potrebbe avere prestazioni inferiori.
 
MA anche funzionalità limtate, e.g. gli snapshot LVM sono imbarazzanti ma non
hanno alternative proprio a causa della mancata integrazione con lo strato
sovrastante (lvmcache invece no, quello è imbarazzante e basta)
 
Enrico

 riparte (non a caso esistono gli ambienti di test ;) )
 
Io sinceramente non saprei cosa fare.
Preferirei evitare ZFS, ma leggendo la m/l di linux-raid, 
sembrerebbe che md non stacchi un disco problematico nonostante 
gli errori in scrittura (o in lettura) per non ho ben capito quale
assurdo motivo (ci sono lunghe discussioni nella mailing list)
 
Il test non è facilissimo, testare una configurazione RAID10 o RAID1+0 o 
RAID1+LVM con 4 dischi è diverso da testarla con 8 o 12 dischi, le
performance sono sensibilmente differenti.
 
Fattostà che al 90% i miei attuali 3 dischi da 8TB, sopratutto se attivo
la compressione di BackupPC (o di ZFS) mi potrebbero bastare per i prossimi
anni a venire.
 
Solo che per quanto riguarda ZFS, ogni volta che si chiede consiglio nella
relativa mailinglist, ti rispondono che devi partire con mille-mila dischi
per avere massime performance. Mah.
Se però io dico che mi servono 8TB, partendo con 2 dischi per arrivare a 3, 
in mirror, non mi puoi proporre di partire con 12 dischi.

 per avere massime performance. Mah.
 
Il problema è che quando citi ZFS pensi sempre ad un ambito enterprise, ovvero
ad un file/database server in produzione e in quel caso ha senso partire subito
con un numero consistente di dischi, al fine di evitare colli di bottiglia nel
momento in cui se ne aggiungono altri
 
Enrico

 momento in cui se ne aggiungono altri
 
 
Vero, comunque adesso faccio qualche test con ZFS, vediamo che succede.
 

 problemi hanno tutte email @suse :-) )
 
Anche nella parte di volume management? Da quanto avevo capito, l'unica parte
rimasta ancora critica era quella di RAID
 
Enrico

 rimasta ancora critica era quella di RAID
 
Sinceramente ? Boh.
Ma credo sia il software con lo sviluppo più lento della storia dell'informatica.
Poi adesso che RedHat è uscita, è praticamente rimasta solo SuSE, dal mio punto
di vista, non finiranno mai.
 
Peccato, perchè ha tutte le carte in regola per essere un ottimo FS, 
ma per ignoti motivi la parte RAID5/6 è sostanzialmente abbandonata perchè 
non sanno come terminarla (!) se provi a scrivere nella mailing list alcuni
sviluppatori propongono una soluzione, altri ne preferiscono un altra etc etc,
son passati anni ed ancora mancano alcune funzioni.......
 
Assurdo

 son passati anni ed ancora mancano alcune funzioni.......
 
Per intenderci, dal wiki ufficiale:
"The write hole is the last missing part, preliminary patches have been posted but needed to be reworked. The parity not checksummed note has been removed."
 
Beh, fixatelo no ? E' ANNI che è così. Da prima del kernel 4.12


Gia`, ma se consideriamo lo stacking,
avendo RAID, LVM, LUKS, FS separati
consente di:
 
1) mettere LUKS dove si vuole e questo
puo` avere un senso anche sotto il RAID
(stesso discorso per LVM)
2) avere il FS che si vuole
3) massimizzare l'isolamento tra i moduli
in modo da ridurre i bug "sinergetici"
 
Inoltre, sara` anche che lo snapshot non
e` il massimo con LVM, ma se quello e`
l'unico motivo allora lo tengo volentieri
cosi`, visti tutti gli altri vantaggi.
 
Riguardo lvmcache, non capisco dove sia
il problema, funziona egregiamente da me.
 
E no, avere cache separate in lettura e
scrittura *non* e` positivo, e` *negativo*.
La cache deve essere unica, altrimenti le
prestazioni vanno a farsi benedire.
 
bye,
 
-- 
 
piergiorgio

 riparte (non a caso esistono gli ambienti di test ;) )
 
Difatti, come gia` scritto, il RAID-10 di
Linux ha vari vantaggi, ma non certo quello
della malleabilita`.
 
bye,
 
-- 
 
piergiorgio

 in modo da ridurre i bug "sinergetici"
 
Ci vuole molto più tempo a configurare tutto lo
stack, le performance sono quasi sicuramente inferiori
ad un software che fa tutto cià nativamente, le
features non sono paragonabili, ad esempio dovrai
sempre e comunque fare rebuild di tutto l'array
anzichè solo dello spazio usato (un array da 20TB
dove ne occupi il 10%, richiede 1 settimana con
mdadm, una manciata di ore con ZFS) e se qualcosa
non dovesse funzionare a dovere, il troubleshooting
sarebbe un inferno, con mille programmini impilati,
non sai mai chi ha rotto cosa.
 
No, non mi piace per niente.
 

 No, non mi piace per niente.
 
Mi ero preparato un lungo discorso
tecnico per spiegare il motivo per
cui una soluzione semplice e` meglio
di una complessa e, quindi, un sistema
stacked (che e` *semplice*) e` meglio
di un sistema complesso come ZFS.
 
Poi ho letto un articolo dove Torvalds
fa la sua ultima sparata dicendo che
non si deve usare ZFS e non mi e` parso
piu` appropriato.
 
bye,
 
-- 
 
piergiorgio

 
 
dov'e' questo articolo?
vorrei leggerlo.

 piu` appropriato.
 
E lo reputi positivo o negativo, il parere di Torvalds?

 vorrei leggerlo.
 
Google: torvalds zfs
 

 E lo reputi positivo o negativo, il parere di Torvalds?
 
E` una faccenda con molti aspetti.
 
Su alcuni punti, come la licenza, ha
sicuramente ragione.
Su altri, come le motivazioni (se cosi`
si puo` dire) di ZFS, penso avrebbe
dovuto essere piu` cauto. Mi e` sembrato
un po' superficiale.
 
ZFS ha ragione di esistere, sicuramente.
 
Ritengo, pero`, che serviranno almeno altri
5~10 anni prima di avere una cosa "affidabile".
 
Il problema e` che ZFS *vuole* essere affidabile,
ma ignora bellamente il fatto che la sua stessa
complessita` lo rende inaffidabile, in maniera
subdola, per giunta.
 
Se scrivessimo di f2fs, che sicuramente e` meno
affidabile, sarebbe una discussione diversa,
proprio perche` f2fs, che e` COW, non ha la
_pretesa_ di essere affidabile.
 
bye,
 
-- 
 
piergiorgio

 subdola, per giunta.
 
ZFS è *estremamente* affidabile.
Il problema è che non perdona, se esegui il comando
errato, puoi tranquillamente segare l'intero pool
con tera e tera di dati, senza che nessuno chieda conferma
o cose simili. Oppure perdi completamente ridondanza perchè
hai aggiungo un disco singolo ad un pool ridondato, non c'è
(non c'era) modo di torgliere il disco errato se non cancellando
tutto con perdita di dati.
 
Questo non lo rende inaffidabile, ma semplicemente complesso. 
ed è ciò che a me non piace.
 
Ma da qui a dire che saranno necessari altri 5-10 anni (su un software
che di anni ne ha già 20) per renderlo affidabile è una forzatura.
 
Forse intendevi ZFS-on-Linux, non ZFS.... Ma anche ZOL è affidabile,
certo, se fosse integrato nel kernel, invece di 5 anni ci vorrebbero
5 mesi ...

On 14/01/2020 22.20, 
gandalf.co...@gmail.com
 wrote:
[...]
Ma avevo scritto che non volevo fare
un resoconto tecnico... :-(
 
bye,
 
-- 
 
piergiorgio

 prestazioni vanno a farsi benedire.
 
ZFS non è d'accordo con te
 
Enrico

 vorrei leggerlo.
 
https://itsfoss.com/linus-torvalds-zfs/
 
 
Enrico

 resto, mi sembra tutto attaccato con lo sputo
 
Sarò talebano, ma se c'è una cosa che NON sopporto è l'utilizzo di UUID non standard.
 
Il formato UUIDv4 permette qualcosa tipo 16^32 combinazioni possibili,
è praticamente impossibile avere una collisione a livello mondiale
 
In merito alle collisioni:
"This number is equivalent to generating 1 billion UUIDs per second for about
85 years, and a file containing this many UUIDs, at 16 bytes per UUID, 
would be about 45 exabytes, many times larger than the largest databases 
currently in existence, which are on the order of hundreds of petabytes."
 
o anche:
 
"Per rendere l'idea, considerando che in tutto l'universo osservabile sono 
contenute 5×10^22 stelle, ad ogni singola stella potrebbero essere assegnati 6.8×10^15 diversi GUID"
 
UUIDv4: f76e9765-f828-4e2f-b6c5-60839cf3d874
UUID LVM: zsgCoO-nRUL-owuP-7Nng-TQcx-lD3F-K3dXiG
 
per quale dannatissimo motivo gli UUID di LVM devono essere assurdamente
fuori standard ?
 
BTRFS mi pare usi UUIDv4
 
Sul resto concordo al 100% con te.

 piu` appropriato.
 
Guarda, ho letto anche io quell'articolo, ma di fatto mi sembra un rant simile
a quello verso Nvidia senza capo ne coda (giusto per fare un esempio, dice che
ZFS ha performance peggiori, ma primo è e rimane un modulo esterno e quindi di
fatto penalizzato da questa condizione, secondo un test del cavolo con FIO su
una mia VPS dice sì, ZFS ha prestazioni peggiori, ma siamo al di sotto del 5%
su una configurazione standard, ovvero senza ottimizzazioni di sorta, roba che
tanto peggiorni non mi sembrano)
 
Enrico