linux user group brescia

immagine del castello

Archivio della mailing list

Fw: RAID IDE

Luca Coianiz luca a coianiz.it
Mer 14 Gen 2004 18:28:52 UTC
On Tue, 13 Jan 2004, Luca Giuzzi wrote:
>On Mon, Jan 12, 2004 at 01:55:29PM +0100, Bauno wrote:
>> >  Mmm... sarebbe interessante approfontire, magari in ML, se partizioni RAID
>> > e partizioni non-RAID possono coesistere:
>> Certo che sì, che problema c'è?
>nessun problema infatti nella coesistenza delle partizioni...
>l'unica cosa e' che le partizioni non-raid quando si guasta il
>disco sono perse!

 Dove per "guasta" intendi "in modo hardware" ovviamente.

>(oh well... se il raid serve ad evitare
>catastrofiche perdite di dati, tutto bene: si reinstalla il sistema
>e si recuperano i dati... se invece la macchina deve SEMPRE FUNZIONARE,
>allora la cosa e' un po' diversa)

 In uno dei messaggi (probabilmente PVT) parlavo di "(quasi) sempre online"
ma non di "high availability": mi sa che per una macchina (anche server)
casalinga è piuttosto normale essere down per qualche ora/giorno/settimana.

 Cioè... molto bello il discorso teorico (e la teoria è sempre meglio
conoscerla)... però bisogna anche calarlo in un discorso "pratico", anche
per (inevitabili) questioni di quattrino (v. anche più sotto).

>>> Recentemente un amico (sistemista Linux (Debian) presso un'azienda
>>> bresciana) m'ha fatto notare una cosa interessante: non conviene tenere
>>> TUTTO il FS in RAID,
>> Eh?
>>> dato che (per la sicurezza) si spreca sempre una parte
>>> dello storage (da c.ca il 30% del RAID-5 al 50% del RAID-1). Conviene
>>> piuttosto mettere in RAID le parti "sensibili" del FS (ad es. la /root o
>>> /sbin) e gestire il resto tramite un FS journaled (Ext3, Reiser, Jfs, Xfs,
>>> ecc.).
>Adesso capisco perche' ci sono problemi con l'economia bresciana :))

 Ma no, ma no... si parlava del mio server "di casa", NON dei suoi in
azienda. ;-)

>Scherzi a parte: /root e /sbin sono directories che si possono sempre
>ricostruire a partire dall'installazione ... /home (o dove uno tiene i
>suoi dati) no!
>[dunque: quale e' piu' importante?]

 Premesso che la tua domanda è esattamente il punto sul quale mi sto
muovendo per la pianificazione di cosa mettere "dentro" e cosa lasciar
"fuori" dal RAID... mettiamola così:

/home			 RAID Journaled
/etc			 RAID Journaled
/usr/local/devel/c	 RAID Journaled
/usr/local/dati/banca    RAID Journaled
/usr/local/dati/bilancio RAID Journaled
/usr/local/film/porno	 Journaled
	  /foto/xxx	 Journaled

 ;-))))))))))

(e chissenefrega se si scassa ./film o ./foto) ;-)

>FS jornaled e RAID rispondono a due esigenze diverse:
> raid serve a evitare di perdere dati in caso di rottura fisica del disco
> (indipendentemente da cosa c'e' sopra).

 Certo... diciamo che se ci metto sopra "il sistema di base" (ovvero "tutto
quel che mi serve dal boot all'operatività al 100%), in caso di crash (anche
fisico) del sistema, posso ripartire in breve tempo ed essere UP "come
prima", anche se "a ranghi ridotti": dopo un down, sei mesi fa, il mio RAID
ci mise 6 ore per sincronizzare i due dischi (40GB)... ma intanto il server
era UP, Apache lavorava, la mail arrivava, i job giravano, ecc. ecc.

> Un FS journaled dovrebbe
> garantire che i dati sul disco (indipendentemente da cosa e' stato
> scritto e/o da eventuali crash di sistema) siano in uno stato
> consistente...

 Se mi si scassa (meccanicamente) il disco dove tengo la collezione di film
porno (perchè quelle facce?!??... so benissimo che anche voi ne avete una
=8-)= =)) posso tranquillamente decidere, almeno per una sera, di guardare
un film in TV (mentre sbackuppo da CD sul nuovo disco). ;-))))))))))))

>Per intenderci: esce la corrente mentre stai scrivendo su di un disco?
> RAID non ti aiuta per nulla, ma ext3 puo' servire.

 Quindi con RAID+Ext3 dovrei stare piuttosto tranquillo... sempre se il
solito Jet della Flash Airlines non decide di schiantarsi su casa mia:
diciamo che NON HO un contratto di disaster recovery... faccio male? ;-)))

> Ti si rompe il disco? il journal non cambia nulla!

 Già... guardo la TV. :-(	];-]

	LC





Maggiori informazioni sulla lista Lug