<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>HOWTO: Multi Disk System Tuning: Struttura del Disco </TITLE>
<LINK HREF="Multi-Disk-HOWTO-12.html" REL=next>
<LINK HREF="Multi-Disk-HOWTO-10.html" REL=previous>
<LINK HREF="Multi-Disk-HOWTO.html#toc11" REL=contents>
</HEAD>
<BODY>
<A HREF="Multi-Disk-HOWTO-12.html">Avanti</A>
<A HREF="Multi-Disk-HOWTO-10.html">Indietro</A>
<A HREF="Multi-Disk-HOWTO.html#toc11">Indice</A>
<HR>
<H2><A NAME="disk-layout"></A> <A NAME="s11">11. Struttura del Disco </A></H2>
<P>
<!--
disco!struttura del disco
-->
<!--
disco!struttura, disco
-->
Con tutto questo in testa siamo pronti per iniziare la struttura.
Ho basato ciò sul mio metodo sviluppato quando ho preso 3 vecchi
dischi SCSI e ho provato tutte le possibilità.
<P>Le tavole nelle appendici sono disegnate per semplificare il processo di
mappatura. Sono state progettate per aiutarvi attraverso il processo di ottimizzazione
come anche per fare un log utile nel caso di riparazione del sistema. Sono
dati anche alcuni esempi.
<P>
<P>
<H2><A NAME="ss11.1">11.1 Selezione per il Partizionamento</A>
</H2>
<P>
<!--
disco!struttura, disco!partizionamento
-->
Determinate le vostre necessità ed organizzate una lista di tutte le
parti del file system che volete posizionare su partizioni separate
ed ordinatele in ordine decrescente di richiesta di velocità e quanto
spazio volete dare ad ogni partizione.
<P>La tabella presente nella sezione
<A HREF="Multi-Disk-HOWTO-20.html#app-a">Appendice A</A>
è uno strumento utile per selezionare quali directory dovreste mettere
su partizioni differenti. È ordinata in ordine logico con lo spazio
per le vostre aggiunte e annotazioni riguardo i punti di montaggio e
sistemi addizionali. Inoltre esso non è ordinato per velocità, invece
le necessità di velocità sono indicate da pallini ('ò).
<P>Se avete intenzione di impostare il RAID annotatevi i dischi che volete
utilizzare e quali partizione volete usare con RAID. Ricordatevi che le
varie soluzioni RAID offrono differenti velocità e gradi di affidabilità.
<P>(Solo per farla più facile assumerò che abbiamo un insieme identico
di dischi SCSI e nessun tipo di RAID).
<P>
<P>
<H2><A NAME="ss11.2">11.2 Organizzare le Partizioni sui Dischi</A>
</H2>
<P>
<!--
disco!struttura, disco!partizioni di mappatura
-->
<!--
disco!struttura, disco!partizioni, mappatura
-->
Quindi ora vogliamo mettere le partizioni sui dischi fisici. Lo scopo
del seguente algoritmo è di aumentare il parallelismo e la capacità
del bus. In questo esempio i dischi sono A, B e C e le partizioni sono
987654321 dove 9 è la partizione con la più alta necessità di velocità.
Partendo da un drive noi 'avremo' la linea della partizione attraverso i
dischi in questo modo:
<P>
<BLOCKQUOTE><CODE>
<PRE>
A : 9 4 3
B : 8 5 2
C : 7 6 1
</PRE>
</CODE></BLOCKQUOTE>
<P>Questo fa sì che la 'somma delle necessità di velocità'
sia il più possibile omogenea per tutti i dischi.
<P>Utilizzate la tabella nella sezione
<A HREF="Multi-Disk-HOWTO-21.html#app-b">Appendice B</A>
per selezionare quale disco utilizzare per ogni partizione al fine
di ottimizzare il parallelismo.
<P>Annotate le caratteristiche di velocità dei vostri dischi e annotate
ogni directory nell'apposita colonna. Siate preparati a mischiare directory,
partizioni e dischi prima di essere soddisfatti.
<P>
<H2><A NAME="ss11.3">11.3 Ordinare le Partizioni sui Dischi</A>
</H2>
<P>
<!--
disco!struttura, disco!ordinare le partizioni
-->
<!--
disco!struttura, disco!partizioni, ordinamento
-->
Dopo di ciò è consigliato selezionare la numerazione delle partizioni
per ciascun disco.
<P>Utilizzate la tabella nella sezione
<A HREF="Multi-Disk-HOWTO-22.html#app-c">Appendice C</A>
per selezionare i numeri di partizione al fine di ottimizzare in base
alle caratteristiche di traccia. Alla fine dovreste avere una tabella
ordinata in ordine crescente per numero di partizione.
Riempite poi questi numeri nelle tabelle presenti nell'appendice A e B.
<P>Troverete utili queste tabelle quando eseguirete il programma di
partizionamento (<CODE>fdisk</CODE> or <CODE>cfdisk</CODE>) e al momento
di fare l'installazione.
<P>
<P>
<H2><A NAME="ss11.4">11.4 Ottimizzazione</A>
</H2>
<P>
<!--
disco!struttura, disco!ottimizzazione delle partizioni
-->
<!--
disco!struttura, disco!partizioni, ottimizzazione
-->
<P>Dopo di ciò, ci sono generalmente poche partizioni che devono
essere 'mischiate' nei dischi sia per farcele entrare sia se ci
fossero considerazioni speciali riguardanti la velocità,
l'affidabilità, file system speciali ecc. In ogni caso, questo
fornisce quello che questo autore crede sia un buon punto di inizio
per un setup completo dei dischi e delle partizioni. Alla fine
è l'utilizzo del momento che determinerà le
necessità reali dopo aver fatto così tante premesse.
Dopo le operazioni preliminari si dovrebbe assumere che arriva il momento
in cui ripartizionare porterebbe benefici.
<P>Ad esempio se uno dei 3 dischi nell'esempio menzionato sopra è molto
lento in confronto agli altri due, un miglior progetto potrebbe essere
il seguente:
<P>
<BLOCKQUOTE><CODE>
<PRE>
A : 9 6 5
B : 8 7 4
C : 3 2 1
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>
<H3>Ottimizzare per Caratteristica</H3>
<P>
<!--
disco!struttura, disco!ottimizzare per caratteristica
-->
<!--
disco!struttura, disco!caratteristiche, ottimizzare per
-->
Spesso i dischi possono essere simili nell'apparente velocità globale
ma qualche vantaggio può essere ottenuto accoppiando i dischi
alla dimensione, alla distribuzione ed alla frequenza di accesso.
Quindi i file binari sono fatti per dischi con accesso rapido che
offre possibilità di accodamento dei comandi, e le librerie sono
fatte per dischi con velocità di trasferimento più ampie dove
IDE offre una buona prestazione rispetto al prezzo.
<P>
<P>
<H3><A NAME="opt-drive-parall"></A> Ottimizzare mediante Parallelizzazione del Disco </H3>
<P>
<!--
disco!struttura, disco!ottimizzare mediante parallelizzazione
-->
<!--
disco!struttura, disco!parallelizzare, ottimizzare mediante
-->
Evitate la contenzione del disco guardando ai task: ad esempio
se state accedendo a <CODE>/usr/local/bin</CODE> ci sono possibilità anche
che avrete molto presto bisogno di file da <CODE>/usr/local/lib</CODE>
quindi posizionarli in dischi separati permette meno ricerca e possibili
azioni in parallelo e caching del drive. È abbastanza probabile che
scegliendo ciò che può apparire inferiore alle caratteristiche del
disco, sarà sicuramente vantaggioso se potete ottenere operazioni in
parallelo. Identificate compiti comuni, che partizioni utilizzano e cercate di
mantenerle su dischi separati.
<P>Giusto per illustrare il mio punto di vista, fornirò un po' di esempi
dell'analisi dei task.
<P>
<DL>
<P>
<DT><B>Software da Ufficio</B><DD><P>come l'editing, l'elaborazione testi ed
i fogli elettronici, sono tipici esempi di software di bassa intensità
sia per quanto riguarda la CPU che l'intensità di disco. In ogni caso,
se doveste avere un singolo server per un grande numero di utilizzatori
non dovreste dimenticare che molto di questo software ha opportunità di
auto salvataggi il che causa traffico extra, generalmente nelle
directory home. Dividere gli utenti su più dischi potrebbe ridurre
la contenzione.
<P>
<DT><B>I news reader</B><DD><P>fanno anche loro auto salvataggi nella directory home
quindi gli ISP dovrebbero considerare di separare le directory home.
<P>Le code delle News sono note per avere directory profondamente ramificate
e gran numero di file molto piccoli. La perdita
di una partizione con le code delle News non è per molti un grande
problema, quindi sono buone candidate per organizzare un RAID 0 con
molti dischi piccoli per distribuire i vari accessi attraverso
alberini multipli. Si raccomanda nei manuali e nelle FAQ del server
delle news INN di mettere le cose delle news e i file <CODE>.overview</CODE>
su dischi separati per installazioni più grandi.
<P>C'è anche una pagina web dedicata all'
<A HREF="http://www.spinne.com/usenet/inn-perf.html">ottimizzazione di INN</A> che sarebbe bene leggere.
<P>
<P>
<DT><B>Le applicazioni database</B><DD><P>possono essere pretenziose sia in
termini di utilizzo del disco che in termini di richiesta di velocità.
I dettagli sono naturalmente specifici alle applicazioni, leggete
la documentazione attentamente tenendo ben presente la richiesta
di spazio su disco. Inoltre considerate il RAID sia per le prestazioni
che per l'affidabilità.
<P>
<DT><B>Leggere ed inviare e-mail</B><DD><P>coinvolge directory home come
anche i file delle code in entrata ed in uscita. Se possibile
mantenete le directory home e i file delle code su dischi
separati. Se siete un server di posta o un hub di posta considerate
di mettere le directory home e i file delle code su dischi separati.
<P>Perdere la posta è una cosa molto brutta, se state gestendo un
ISP o un hub principale. Riflettete sul fatto di fare RAID della
vostra posta e considerate backup frequenti.
<P>
<DT><B>Lo sviluppo di software</B><DD><P>può richiedere un gran numero di directory
per file binari, librerie, file include, nonch sorgenti e
file di progetto. Se possibile dividete il più possibile su dischi
separati. Su piccoli sistemi potete posizionare <CODE>/usr/src</CODE>
e i file di progetto sullo stesso disco delle directory home.
<P>
<DT><B>Navigare il Web</B><DD><P>sta diventando sempre più popolare. Molti
browser hanno una cache locale che può espandersi in volumi abbastanza
grandi. Dal momento che questa è utilizzata per richiamare le pagine e
nel ritornare alle pagine precedenti, la velocità è abbastanza
importante in questi casi. Se invece siete connessi attraverso
un proxy server ben configurato, non avete bisogno di più di
pochi megabyte per utente per sessione.
Controllate anche le sezioni sulle
<A HREF="Multi-Disk-HOWTO-10.html#server-home-dirs">Directory Home</A>
e
<A HREF="Multi-Disk-HOWTO-10.html#www">WWW</A>.
<P>
<P>
</DL>
<P>
<P>
<H2><A NAME="ss11.5">11.5 Compromessi</A>
</H2>
<P>
<!--
disco!compromessi
-->
Un modo per evitare le trappole menzionate è semplicemente di dedicare
le partizioni fisse a directory di dimensione ben nota come swap,
<CODE>/tmp</CODE> e <CODE>/var/tmp</CODE> e raggruppare insieme i richiami
nelle partizioni rimanenti utilizzando link simbolici.
<P>Esempio: un disco lento (<CODE>discolento</CODE>),
un disco veloce (<CODE>discoveloce</CODE>) ed un assortimento di file.
Avendo organizzato <CODE>swap</CODE> e <CODE>tmp</CODE> sul <CODE>discoveloce</CODE>;
e <CODE>/home</CODE> e root sul discolento abbiamo le rimanenti directory fittizie
<CODE>/a/lento</CODE>, <CODE>/a/veloce</CODE>, <CODE>/b/lento</CODE> e <CODE>/b/veloce</CODE>
da allocare sulle partizioni
<CODE>/mnt.discolento</CODE> e <CODE>/mnt.discoveloce</CODE> che rappresentano
le rimanenti partizioni dei due dischi.
<P>Mettere <CODE>/a</CODE> o <CODE>/b</CODE> direttamente su entrambe i dischi,
conferisce le stesse proprietà alle sottodirectory. Potevamo fare
tutte e 4 le directory come partizioni separate ma perderebbe un po' di
flessibilità nella gestione della dimensione di ciascuna directory.
Una soluzione migliore è quella di fare link simbolici delle 4
directory a directory appropriate sui rispettivi dischi.
<P>Quindi facciamo
<P>
<BLOCKQUOTE><CODE>
<PRE>
/a/veloce punta a /mnt.discoveloce/a/veloce o /mnt.discoveloce/a.veloce
/a/lento punta a /mnt.discolento/a/lento o /mnt.discolento/a.lento
/b/veloce punta a /mnt.discoveloce/b/veloce o /mnt.discoveloce/b.veloce
/b/lento punta a /mnt.discolento/b/lento o /mnt.discolento/b.lento
</PRE>
</CODE></BLOCKQUOTE>
<P>e abbiamo tutte le directory veloci sul disco veloce senza dovere
organizzare una partizione per le 4 directory.
La seconda alternativa ci da un file system più piatto che in questo caso
rende più semplice tenere sotto controllo la struttura.
<P>Lo svantaggio è che all'inizio è uno schema complicato da mettere
su e da pianificare e che tutti i punti di montaggio e le partizioni devono
essere definiti prima dell'installazione del file system.
<P>
<P>
<P>
<HR>
<A HREF="Multi-Disk-HOWTO-12.html">Avanti</A>
<A HREF="Multi-Disk-HOWTO-10.html">Indietro</A>
<A HREF="Multi-Disk-HOWTO.html#toc11">Indice</A>
</BODY>
</HTML>
