Newsgroup: it.comp.os.linux.sys
Titolo: [un po' OT] idea nuova per filesysem..

Ciao a tutti,
non sono proprio certo che l'idea sia nuova, ma vorrei raccogliere a
riguardo un po' di informazioni.
Mi chiedevo come mai non mi risulti che esista un filesystem di rete che
sfrutti lo spazio libero nei block per scrivere della parità sui dati che
possa essere utilizzata qualora venga a mancare una parte dell'informazione
relativa.
Oggi lo spazio non manca certo, ed i blocchi come sapete, non sono sempre
pieni anzi, spesso lo sono in parte: allora perchè non riempirli con
informazioni che permettano di ricostruire i dati, sritti in punti diversi
in rete, se una parte manca?
Intendo ovviamente qualcosa di più funzionale della minima parità già
esistente, una tecnica simile a quella del raid 5/6.
Sfruttando una sottorete dedicata, in stile SAN per capirci ma senza usare
il FC che costa un occhio, con una spesa contenuta sarebbe possibile
ottenere un filesystem ditribuito altamente ridondante, magari non
velocissimo, ma certamente sicuro...
Ditemi se avete informazioni circa un FS che faccia qualcosa del genere, o
dove posso postare l'idea perchè la legga qualche geniaccio e mi mandi a
quel paese....
Vostre opinioni veramente ben accette.
Techs

 esistente, una tecnica simile a quella del raid 5/6.
puoi provare a utilizzare proprio il software raid su Network Block 
Device, non so se funziona, ma nel software raid howto si legge:
[...]
Il RAID per Linux può funzionare sulla maggior parte dei dispositivi a
blocchi. Non importa se usate dispositivi SCSI o IDE o una loro
combinazione. Alcuni hanno usato il Network Block Device (NBD) con più o
meno successo.
[...]
cya
Banana

Ciao
non mi riferivo a questo, esistono ENBD e NBD che uso già e funzionano, non
serve nemmeno fare il raid 1.
Intendo qualcosa di più... sullo stile di ENFS, MFS, coda ed intermezzo, che
però non conosco bene, e non mi pare che includano una cosa del genere.
Poi pensa se utilizzassi delle unità di rete per fare un raid 5, che razza
di traffico genero!!!
L'algoritmo di parità è ottimizzato per lavorare su certi canali con una
certa banda, stabile e continuativa.
In rete è troppo facile che cada una connessione, ci vuole un modulo che
gestisca il filesystem in maniera trasparente con una certa elasticità.
Il raid sarebbe in risincronizzazione continuamente, cioè sicuramente perdi
tutto..
Non è una cosa da 5 minuti ma da studiare e valutare.
Ciao
Techs

 certa banda, stabile e continuativa.
Mi riaggancio a questa frase per fare una domandina :-)
Hai un link o della doc dove posso trovare info sugli algoritmi
utilizzati nel raid software, e dove sia spiegato benino come funziona
la parità in un filesystem?
Lo so che basterebbe leggere i sorgenti del kernel, ma non sono in grado
di leggere il C.
TIA
Banana

Sto rispondendo al tuo post di prima.
Techs.

 in rete, se una parte manca?
Se ho capito bene...
se ho un file da 6k e blocchi da 4k me ne avanzano 2 su un "blocco" e tu li 
vuoi scrivere un "crc"
Il problema e' che il "blocco" e' per definizione l'unita' minima che il 
file system "indirizza"....
A questo punto riduco i blocchi a 2k e ne alloco alla bisogna x il crc

 A questo punto riduco i blocchi a 2k e ne alloco alla bisogna x il crc
OK, ma allora perchè i filesystem di un certo peso usano blocchi da 512K o
1024K?
Perchè al di sotto di un certo block size in volumi grandi hai problemi di
indirizzamento e di velocità, mentre maggiore è la dimensione del blocco,
maggiore è la velocità del FS, e più grandi sono le partizioni gestibili.
Se noi usiamo un blocco standard da 512k e lo riempiamo con il "crc"
l'operazione di scrittura è una.... se metti il blocco nano e il crc alla
bisogna sono 2...
hai già un risparmio in termini di accesso, lettura e scrittura, in più se
il crc è legato al dato in quel block, hai più coerenza che mettendolo
altrove, senza contare che devi anche implementare un sistema per registrare
dove l'hai messo e poi andarselo a prendere...
In rete non mi sembra molto efficace...
Bene accette le critiche, avanti che voglio capire se è una cag.....ta.
Techs

 1024K?
Con un intero senza segno a 32 bit puoi indirizzare 2^32 blocchi da 1024 
byte. Ovvero 4 terabyte. Non e` una quantita` enorme, ma neanche da 
buttar via ;-)
Quali sarebbero questi FS che hanno bisogno  di blocchi da da un mega 
(hai detto 1024K)?
Uno che ad esempio li indirizza con 16 bit e basta, per toppare a 64 GB?
Mah... ;-)
-- 
   |   \    \  | ___|_  |_  | ianezz a casa sua... :-)
   |  _ \  | \ | _|    /   /  Visita il LinuxTrent a
  _|_/  _\_|  _|____|___|___| 
http://www.linuxtrent.it

 (hai detto 1024K)?
XFS su SGI Irix di default usa 1024K a blocco. Ovviamente modificabile.
Ed indirizza qualche decina di migliaia di Terabyte su MIPS 64bit.
Bello da dire ma non serve granchè ora come ora.
Nel campo del video professionale e della grafica, dove lavoro, gli utenti
si smazzano spesso decine di Giga in rete ed i file "operativi" più
insignificanti (1 frame) sono circa 12 Mb.
Considera però un blocco medio da 512 Kb, in un filesystem normale quanto
pesa il file medio??? Poco meno credo.
Pensiamo ad una bella server farm, od una render farm.
200 macchine a basso costo con un disco "striminzito" da 40 Gb, 2 Gb di
swap, 1 Gb OS, sono 37 Gb (meno in realtà ma facciamo i conti della serva) a
macchina per 200 macchine, fa... vediamo ... uhmm 2+2... 7400 Gb... se
calcolo 1 Thera = 1024 Gb sono.....  7,2 Tb!
Fare una SAN da 7 Tb sai quanto costa??? E di sicuro non la usi così, non
perchè non sarebbe comodo, ma perchè il rapporto costo beneficio è
svantaggioso.
In questo esempio, i dischi sono piccoli e le macchine tante, aumenta i
dischi e diminuisci le macchine ed il nostro FS diventa una cosa che serve
;-) , sempre che sia utile e fattibile.
Son contento, vi prego di non abbandonare questa thread, tra voi ci sono
persone molto competenti che mi possono dare un parere spassionato a cui
tengo molto.
Probabilmente in questa chiacchierata viene fuori anche qualche cacchiata e
sono il primo a mettermi in lista, ma be venga! C'è sempre da imparare!
Ciao a tutti
Techs

 XFS su SGI Irix di default usa 1024K a blocco. Ovviamente modificabile.
Secondo me hai letto male:
XFS
...
File System Block Size
Selectable at file system creation time using mkfs_512, 512 bytes to 
64KB for normal data, and up to 1MB for real-time data
...
Quindi il blocco da 1MB non e` proprio default,
ma e` usato per "real-time" data.
Blocchi molto piu` piccoli sono considerati...
In caso di filesystem distribuito, non so se un
blocco grosso sia meglio di uno piccolo, bisognerebbe
vedere l'overhead di trasmissione vs. l'overhead
del blocco stesso.
L'idea di un FS distribuito con parita` non e`
nuova, il problema e` il traffico generato sulla
rete, che di solito rappresenta il vero limite.
L'unica soluzione convincente e` trovare algoritmi
di caching molto, ma molto, scaltri. Tali da usare
al meglio la banda disponibile.
bye,
-- 
   Piergiorgio Sartor

 al meglio la banda disponibile.
Questo sicuramente, ma valutando una soluzione come sopra, sarebbe possibile
limitare la problematica ad un layer 1 dedicato che non coinvolgerebbe gli
altri protocolli di rete.
Credo sarebbe molto più semplice da progettare, avendo dei parametri
assoluti da valutare, e non relativi ad un contesto dove i layer possono
essere congestionati da una miriade di situazioni random, di impossibile
gestibilità.
Se consideri 80 Mb/s max teorici al secondo per una rete 1000 base T (che
lavora a 640 Mbit non a 1000 come la fibra), sacrifica il 20% per essere
concreto, mi pare ci sia spazio per avere un 40% di banda per la
trasmissione e un 40% di banda per la replicazione ed il balancing, il che
vuol dire circa 32 Mb al secondo per "canale", che sono il limite di un ATA
di questa generazione.
Riducilo anche ad una 100 base TX, parliamo sempre di 3,2 Mb/s, che non sono
da buttare per tanti utilizzi
Non mi pare male considereando che l'obiettivo è la sicurezza.
Il problema sarebbe certo anche nello studio delle policy di balancing e
replicazione: come lo scrivo, dove lo scrivo, perchè proprio lì e via
dicendo.
Premetto che, purtroppo per me, non ho basi di programmazione ne il tempo di
farmele, il mio è un ragionamento e basta, da sottoporre eventualmente a chi
ne sa più di me.
Grazie sinceramente per il confronto.
Techs

 altri protocolli di rete.
Il problema e` se tale network array sia solo
per un unico utente o per tutti gli utenti
connessi alla stessa rete e/o array.
Nel secondo caso devi moltiplicare la banda
singola per il numero di utenti.
Attualmente un HD IDE riesce a fare 30MB/sec in
sustained mode e circa 20MB/sec in random mode
(o meno, dipende da varie cosette).
Moltiplica per 10 utenti, dobbiamo arrivare a
300MB/sec sustained mode, cioe` 2400Mb/sec, senza
considerare la parita` (B=byte, b=bit).
Ti serve una rete che regga tale traffico...
Oppure limiti i trasferimenti in lettura (quelli
dominanti) memorizzando l'array sul disco locale
e gestendo in qualche modo le modifiche.
bye,
-- 
   Piergiorgio Sartor

 dell'informazione relativa.
Forse perche' oggi l'affidabilita' delle reti e' molto alta.
C'e' gia' il checksum ethernet e quello UDP o TCP, un ulteriore
checksum non aggiungerebbe molto, IMO.
-- 
Lorenzo

 checksum non aggiungerebbe molto, IMO.
La parità è relativa ai dati stoccati ed alla ridondanza del filesystem, non
alla trasmissione.
Piergiorgio ti sto rispondendo abbi pazienza che mi costi caro di
ragionamenti :-)) ed obiezioni!!
Saluti
Techs