Newsgroup: it.comp.os.linux.sys
Titolo: filesystem RAID

Salve, qualcuno sa se esiste un filesystem che, utilizzando
piu` volumi, fornisca una ridondanza pari a RAID-5 o 6?
In altri termini, un FS che, montato su piu` partizioni, si
occupi da solo di salvari dati e parita` varie in maniera
trasparente ed indipendente dal block device sottostante.
Grazie,
bye,
-- 
piergiorgio

 ha scritto 
nel messaggio news:ev1vs5-...@lazy.lzy...


 ottimo compromesso
Il problema e` il tempo di ricostruzione del RAID,
che e` sempre lo stesso anche se l'array e` mezzo
vuoto, dato che il block device e` FS un-aware.
Esistono soluzioni proprietarie che implementano
tale tipo di RAID, mi chiedevo se ci fosse anche
qualcosa per Linux.
bye,
-- 
piergiorgio

 qualcosa per Linux.
Non ho idea di dove sia arrivato il supporto su Linux, ma in teoria ZFS...
E' per dire, che indipendentemente da tutto per ora non penso sia 
utilizzabile per *farci* qualcosa di diverso dai test...
-- 
http://bofhskull.wordpress.com/

 utilizzabile per *farci* qualcosa di diverso dai test...
Beh, non si puo` avere tutto nella vita... :-)
bye,
-- 
piergiorgio

 piu` volumi, fornisca una ridondanza pari a RAID-5 o 6?
AFAICT di stabile non c'è ancora nulla, e sinceramente non so se ve ne siano
anche in progetto che agiscano come raid 5/6.
Vi sono alcuni progetti che implementano un FS distribuito con ridondanza
dei dati e controlli di integrità, ma non so se è quello che ti interessa.
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 ZFS...
Sulla carta è il fs/vm definitivo.
Sto per testarlo su un solaris_x86.
Se solo cambiassero quella licenza...

 dei dati e controlli di integrità, ma non so se è quello che ti interessa.
Tipo? Dammi qualche riferimento, che poi ci butto un'occhio.
Thanks,
bye,
-- 
piergiorgio

 No, proprio un filesystem.
Che io sappia, attualmente non esiste nulla che faccia una cosa del
genere (eccetto il RAID software, of course). Forse una futura
estensione di LVM, o di uno dei due file system del momento (Ext4 e
Brtfs), ma nulla di veramente usabile. Se il tempo di ricostruzione
dell'array e` un punto critico, forse ti conviene far acquistare un
controller RAID e passare ad una vera soluzione hardware
Enrico
P.S. per curiosita`, perche` RAID 5? Personalmente lo trovo inutile per
il 95% dei compiti, ma nel mio caso le prestazioni sono una componente
fondamentale

 fondamentale
Uhm, sono a caccia di un dispositivo storage tipo drobo,
che offra cioe` ridondanza contro rotture degli HD, che
sia esterno, che sia espandibile e che non debba stare
accesso per giorni quando tocca ricostruire l'array o,
peggio, quando lo si espande.
Il suddetto drobo offre tutto cio` e per fare questo
e` filesystem aware. Riconosce FAT, NTFS ed ext3.
Solo che, oltre ad essere una soluzione proprietaria,
risulta non versatile, per esempio non si puo` creare
un array crittografato, si deve usare un overlay FS,
tipo encfs, per lo stesso scopo.
Pensavo allora di mettere assieme un PC, tipo HTPC,
con un RAID software. Tutto funzionerebbe, anzi
funziona perfettamente, solo che cambiare l'array
causa un tempo di ricostruzione/espansione oltre il
limite dell'accettabile (da me).
Oltre che aumentare il rischio, viste le tempistiche.
Chiaramente la soluzione e` avere un array che sia FS
aware, come drobo, o meglio un FS che sia anche RAID...
bye,
-- 
piergiorgio

 Tipo? Dammi qualche riferimento, che poi ci butto un'occhio.
AFS e GFS, se non ricordo male, implementano la ridondanza
Enrico

 limite dell'accettabile (da me).
Tutto questo non spiega perche` RAID 5 :)
Comunque, personalmetne non ho mai notato problemi durante la
ricostruzione di un array (eccetto un piccolo calo di prestazioni).
Personalmente, per il lavoro che ti sei prefissato, ti consiglierei di
fare n array in RAID 1 e poi unirli via LVM
Enrico

 Tipo? Dammi qualche riferimento, che poi ci butto un'occhio.
Non mi sovviene come si chiamava, ma ricordo bene che l'ho letto tra i feed
di kerneltrap.org... Roba dell'ultimo anno.
Recentemente è passato tux3 che sulla carta potrà diventare qualcosa di carino.


 Se solo cambiassero quella licenza...
Io ci sto giochicchiando ora con un Solaris/SPARC ed è una figata :) Un po'
meno il supporto di ldom a Linux (e viceversa).
-- 
Vide

 meno il supporto di ldom a Linux (e viceversa).
Ecco. Io al massimo ho una VM opensolaris su cui ho fatto due minchiate.
Quando vuoi, quando puoi, un commentino dettagliato via email è ben 
gradito ;-)
-- 
http://bofhskull.wordpress.com/

 fare n array in RAID 1 e poi unirli via LVM
Uhm, ma con 8 dischi, per esempio, mi ritrovo la
capacita` di 4, gia` un RAID-6 andrebbe meglio.
Come scritto sopra, le prestazioni non interessano,
dato che tale array sarebbe collegato via eth od USB.
bye,
-- 
piergiorgio

 dato che tale array sarebbe collegato via eth od USB.
Come dicevo sopra, se operativamente non ti interessa, le prestazioni
entrano in gioco nel momento in cui devi ricostruire l'array, in quanto
il calcolo della parita` e` un procedimento che richiede molte risorse.
Per fare una prova, la creazione di file di parita` di un archivio tar
di 7.5GB (giuro che e` un caso), sul mio Q6600 quad, ha impegnato la cpu
per circa il 50-60%, e ci ha messo il seguente tempo (misurato con time):
real	18m0.243s
user	12m34.571s
sys	0m22.529s
Personalmente, a questo punto, penso che ti convenga fare anche delle
prove
Enrico
P.S. se ti puo` interessare, con le impostazioni predefinite in
Debian Lenny, par2 ha creato 385.5MB di file di parita`

 prove
Non so se questo test sia significativo per un RAID-5.
Probabilmente legge e scrive sullo stesso disco e la
parita` non e` necessariamente equivalente, nel senso
che par2 puo` generare diversi livelli di ridondanza.
Il problema principale e` l'I/O, per ricostruire un volume
RAID-5 servono due letture ed una scrittura.
Cioe` se il bus, ammesso che sia unico, ha una capacita`
di 120MB/sec, ci si ritrova con 40MB/sec di velocita` di
ricostruzione.
La CPU riesce a starci dietro facilmente. Oddio, sempre di
una valanga di dati si tratta...
Se pero`, per disgrazia, l'array e` su USB, con 30MB/sec,
la ricostruzione viaggia a 10MB/sec.
Un disco da 500GB richiede, nella migliore delle ipotesi,
quasi 14 ore solo di I/O.
Il problema, da cui la domanda, e` che tale procedura
ricostruisce tutto, anche i blocchi non utilizzati.
Avendo un FS RAID, questo deve "solo" ricostruire i file
ed i metadati.
Non solo, ma se questo e` fatto bene e` anche interrompibile.
Un altra possibilita` sarebbe quella di micro-partizionare i
dischi sottostante l'array e fare cosi` tanti "piccoli" RAID 5/6
da poi unire in LVM.
La ricostruzione puo` essere cosi` fatta a "rate".
Ripeto, il target sarebbe un dispositivo storage tipo il
drobo, solo con un pelo di maggiore versatilita`.
Tra l'altro un secondo problema e` il case...
Non sono ancora riuscito a trovarne uno decente...
bye,
-- 
piergiorgio

 Tutto questo non spiega perche` RAID 5 :)
Dimenticavo, cosa importatissima, il RAID 5, e credo
anche il 6, possono essere accresciuti aggiungendo un
singolo HD.
In questo scenario, uno puo` partire, in RAID 5, con
solo 2 (due, non tre) HD e poi, pian piano, aumentare
la capacita` dell'array aggiungendo un disco alla volta.
bye,
-- 
piergiorgio

 singolo HD.
Beh, questo lo fai anche con LVM (ovviamente dimenticandoti la
ridondanza per quel disco)
Enrico

 ridondanza per quel disco)
Eh! Appunto! :-)
Scherzi a parte, far crescere un RAID-5 da 2 a 3 dischi
richiede piu` tempo che ricostruire il RAID stesso.
Non solo, ma se succede qualcosa durante il "grow", non
so come siamo messi...
bye,
-- 
piergiorgio

 
questo manderebbe al creatore la sicurezza, no?
partire con un sistema raid 5 con due dischi soli (senza, quindi, quello
di parità) mi sembra una gran minchiata a priori.
tra l'altro, di solito, se fai un raid 5 con tre dischi e domani ne
aggiungi un quarto più grosso, del quarto comunque usi solo
l'equivalente di uno degli altri. mi spiego:
se hai tre dischi da 100 gb in raid 5, e domani (per svariati motivi) ne
 aggiungi un quarto da 200, il raid occupa comunque solo 100 gb
nell'ultimo disco.

 
di solito nei controller "seri" la batteria di backup serve proprio a
quello... ma se murphy ci mette il naso possono succedere un sacco di
cose (ma non leggere più in basso se sei debole di cuore):
controller rotto
batteria rotta
cache rotta
ti si rompe uno degli altri dischi
ti va a fuoco

 nell'ultimo disco.
Non e` un problema quello, all'aggiunta successiva,
oppure al rimpiazzo di uno dei 100GB, si fa un
secondo RAID, con i 100+100GB rimasti e si aggiunge
tramite LVM.
Ovviamente ogni _partizione_ solitaria non e` utilizzabile.
In altri termini.
Si parte, per es., 100+100GB, RAID-5.
Dopo un po' si aggiunge un 200GB, ovviamente partizionato
in 100+100. Di questi solo (i primi) 100GB sono utilizzabili.
Si rompe un 100GB, si rimpiazza con un altro 200GB, anche
questo partizionato 100+100. Una partizione ripara il primo
RAID-5 (3 volumi da 100GB), la seconda si mette, sempre in
RAID-5, con l'altra partizione inutilizzata da prima, creando
un secondo volume da 100GB.
Si hanno cosi` due volumi RAID, uno da 3 partizioni e 200GB,
uno da 2 partizioni e 100GB.
Questi si combinano tramite LVM ottenendo 300GB totali e
la sicurezza contro la rottura di un singolo HD.
Ovviamente, come gia` scritto, questo non protegge contro i
soft error o gli errori umani, quindi sarebbe meglio usare
RAID-6, che pero` non saprei se parte da 3 dichi, forse ne
servono 4 da subito. Per il resto, pero`, e` lo stesso.
bye,
-- 
piergiorgio

 di parità) mi sembra una gran minchiata a priori.
Penso intendesse che parti con il mirror e poi estendi trasformando in raid5.


 da poi unire in LVM.
Penso che sia l'unica. Tieni presente questo: da quello che ho capito,
il device USB e` bloccato a circa 20MByte/sec quindi, se come hai detto
probabilmente la cpu ci sta dietro (anche se mi rimangono dei dubbi),
non ci stai dietro con la banda I/O. Probabilmente ti converrebbe
pensare di mettere in piedi una struttura tipo esata, piuttosto che
basarti su USB o su ethernet, che sono notevolmente piu` lenti
Enrico
P.S. il fatto dei 20MByte/sec l'ho visto oggi creando un array in RAID 1
con due dischi da 80GByte montati via USB. Da quello che ho capito sul
discorso, dovrebbe essere fattibile aumentare l'ampiezza, ma non sono
riuscio a trovare come

 riuscio a trovare come
Uhm, che vuoi dire con "aumentare l'ampiezza"?
Intendi forse "aggiungere un disco"?
bye,
-- 
piergiorgio

 Intendi forse "aggiungere un disco"?
No, intendo l'ampiezza di banda I/O passante per il canale USB. Come ho
detto, dovrebbe essere fattibile, in quanto il limite dovrebbe essere
impostato come parametro del kernel, ma non ho capito come si fa
Enrico

 impostato come parametro del kernel, ma non ho capito come si fa
Sicuro-sicuro che sia possibile?
Perche` da quello che si legge in giro, dipendentemente
dall'HW (i.e. intel od altro), non si tira molto di piu`
di quello.
Io sono arrivato, su intel ICH5 (quindi non nuovissimo)
a 30MB/sec.
La stessa identica configurazione, SW, HD, IDE<->USB, ma
con HW nVidia 6150 (piu` recente di ICH5) arriva a 15MB/sec.
Ho cercato se vi sono parametri del kernel, ma non ho
trovato nulla di interessante.
Ogni suggerimento e` comunque benvenuto!
bye,
-- 
piergiorgio

 Sicuro-sicuro che sia possibile?
Boh, sinceramente a me lo hanno detto, e come te ho provato a cercare
qualche informazione, ma nemmeno io ho trovato qualcosa. A questo punto
non saprei nemmeno dire se si tratta di una leggenda metropolitana o meno
Enrico