<!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 File System</TITLE> <LINK HREF="Multi-Disk-HOWTO-5.html" REL=next> <LINK HREF="Multi-Disk-HOWTO-3.html" REL=previous> <LINK HREF="Multi-Disk-HOWTO.html#toc4" REL=contents> </HEAD> <BODY> <A HREF="Multi-Disk-HOWTO-5.html">Avanti</A> <A HREF="Multi-Disk-HOWTO-3.html">Indietro</A> <A HREF="Multi-Disk-HOWTO.html#toc4">Indice</A> <HR> <H2><A NAME="s4">4. Struttura del File System</A></H2> <P> <!-- disco!struttura del file system --> Linux è stato multi tasking dall'inizio, da quando un bel numero di programmi interagivano e giravano ininterrottamente. In ogni caso è importante mantenere una struttura dei file su cui tutti potrebbero essere d'accordo, in modo che il sistema trovi i dati dove ci si aspetta di trovarli. Storicamente ci sono stati così tanti standard differenti che si è creata confusione e la compatibilità è stata mantenuta usando collegamenti simbolici, il che ha fatto ancora più confusione e la struttura è finita col sembrare un labirinto. <P> <!-- disco!FSSTND --> Nel caso di Linux, uno standard chiamato il <EM>File Systems Standard</EM> (FSSTND) fu fortunatamente accettato all'inizio e oggi è utilizzato dalle maggiori distribuzioni Linux. <P> <!-- disco!FHS --> <P>Più tardi, venne deciso di creare un successore che supportasse anche altri sistemi operativi oltre al solo Linux e venne chiamato <EM>Filesystem Hierarchy Standard</EM> (FHS) attualmente alla versione 2.1. Questo standard è in continua evoluzione e sarà quanto prima adottato dalle distribuzioni Linux. <P>Vi consiglio di non sviluppare una vostra struttura personale visto che una marea di pensieri è servita per avere gli standard e molti pacchetti si conformano a questi standard. Invece, potete leggere di più su questo presso l'home page del <A HREF="http://www.pathname.com/fhs">FHS</A>. <P>Questo HOWTO si sforza di conformarsi al FSSTND e perseguirà il FHS quando le distribuzioni saranno disponibili. <P> <P> <H2><A NAME="ss4.1">4.1 Caratteristiche del File System</A> </H2> <P> <!-- disco!caratteristiche del file system --> Le varie parti di FSSTND hanno diverse necessità riguardo la velocità, l'affidabilità e la dimensione, ad esempio perdere root è un dolore ma può essere facilmente recuperabile. Perdere <CODE>/var/spool/mail</CODE> è una cosa abbastanza differente. Ecco un veloce sommario di alcune parti essenziali e delle loro proprietà e necessità. Badate che questa è solamente una guida e ci potrebbero essere file binari nelle directory <CODE>etc</CODE> e <CODE>lib</CODE>, librerie nelle directory <CODE>bin</CODE> e così via. <P> <P> <H3>Swap</H3> <P> <!-- disco!swap --> <DL> <DT><B>Velocità</B><DD><P>Il massimo! Sebbene facciate troppo affidamento sullo swap, dovreste considerare di comprare più RAM. Notate comunque, che su molte schede madri, la cache non funzionerà se la RAM è superiore a 128 MB. <P> <DT><B>Dimensione</B><DD><P>Stesso discorso della RAM. Un algoritmo veloce e sporco: un po' come per il tè: 16 MB per la macchina e 2 MB per ogni utente. Il kernel più piccolo gira in un mega ma sta stretto. Usate 4 MB per il lavoro in generale e applicazioni leggere, 8 MB per X11 o GCC o 16 MB per stare più comodi. <P>(Si sa che l'autore prende tazze di tè abbastanza potenti...) <P>Alcuni suggeriscono che lo spazio di swap debba essere 1-2 volte la dimensione della RAM, evidenziando che la localizzazione dei programmi determina quanto sia efficace lo spazio swap aggiunto. Notate che usare lo stesso algoritmo come per 4BSD è abbastanza scorretto dal momento che Linux non riserva spazio per pagine in core. <P>Un approccio più preciso è considerare lo spazio di swap più la RAM come il vostro insieme lavorativo totale, così se sapete quanto spazio, al massimo, vi serve, sottraete la RAM fisica che avete e che è lo spazio di swap di cui avrete bisogno. <P>C'è inoltre un'altra ragione per essere generosi quando dimensionate il vostro spazio di swap: i furti di memoria. Programmi che funzionano male, che non liberano la memoria che riservano per loro stessi si dice che provocano un furto di memoria. Questa allocazione rimane anche dopo che il programma incriminato è terminato e quindi questo è fonte di consumo di memoria. Una volta che tutta la RAM fisica e lo spazio di swap sono esaurite, l'unica soluzione è fare un reboot e cominciare da capo. Per fortuna questi programmi non sono così comuni ma se voi ne doveste incontrare qualcuno, troverete che uno spazio swap extra, vi prenderà più tempo tra i riavvii. <P>Ricordate inoltre di prendere in considerazione il tipo di programma che usate. Alcuni programmi che hanno grandi ambienti di lavoro, come quelli di modellazione agli elementi finiti (FEM), hanno raffinatissime strutture di dati caricate nella RAM piuttosto che lavorare esplicitamente sui file. Programmi per i dati e per il calcolo complessi come questi, causeranno swapping eccessivo se avete meno RAM del necessario. <P>Altri tipi di programmi possono bloccare le loro pagine nella RAM. Questo può accadere per motivi di sicurezza, prevenendo copie dei dati che raggiungono un dispositivo di swap o per motivi di prestazioni come nel modulo in tempo reale. In ogni caso, bloccare queste pagine, riduce il quantitativo di memoria swappabile rimanente e può fare in modo che il sistema swappi prima di quanto ci si possa aspettare. <P>Nel <CODE>man 8 mkswap</CODE> c'è spiegato che ogni partizione di swap può essere massimo 128 MB in dimensione per macchine a 32-bit e 256 MB per macchine a 64-bit. <P> <DT><B>Affidabilità</B><DD><P>Media. Quando fallisce sapete lo fa rapidamente e il fallimento vi costerà qualche perdita di lavoro. Salvate spesso, no? <P> <DT><B>Nota 1</B><DD><P>Linux offre la possibilità di distribuire lo swapping su più dispositivi, una caratteristica che vi può far guadagnare parecchio. Controllate "<CODE>man 8 swapon</CODE>" per maggiori dettagli. Tuttavia, il guadagno di utilizzare un disco RAID per lo <CODE>swap</CODE> potrebbe essere vanificato dalla maggiore pesantezza del codice di RAID. <P>Perciò il file <CODE>/etc/fstab</CODE> potrebbe somigliare a questo: <BLOCKQUOTE><CODE> <PRE> /dev/sda1 swap swap pri=1 0 0 /dev/sdc1 swap swap pri=1 0 0 </PRE> </CODE></BLOCKQUOTE> Ricordate che il file <CODE>fstab</CODE> è <EM>molto</EM> sensibile alla formattazione utilizzata, leggete le pagine man attentamente e <EM>non</EM> fate un semplice taglia e incolla delle righe qui sopra. <P> <DT><B>Nota 2</B><DD><P>Qualcuno per swappare utilizza un RAM disk o qualche altro file system. In ogni caso, se non avete impostazioni o necessità inusuali, difficilmente trarrete vantaggio da questo e questo porta ad usare la memoria a disposizione per le operazioni di cache e buffer. <P> <DT><B>Nota 2b</B><DD><P>C'è un'eccezione: su un numero di schede madri mal disegnate, la memoria cache integrata su piastra madre non è in grado di porre in cache tutta la RAM che può essere indirizzata. Molte schede madri vecchie, erano in grado di accettare 128 MB di RAM ma potevano porre in cache solo le prime 64. In questi casi, aumenterebbe la prestazione se voi utilizzaste gli ultimi 64 MB di RAM come swap basato su RAMdisk o come altro supporto di memorizzazione temporaneo. <P> </DL> <P> <P> <H3>Archiviazione Temporanea (<CODE>/tmp</CODE> e <CODE>/var/tmp</CODE>)</H3> <P> <!-- disco!archiviazione temporanea --> <DL> <DT><B>Velocità</B><DD><P>Molto alta. Su un disco/partizione separati questo generalmente ridurrà la frammentazione, sebbene <CODE>ext2fs</CODE> gestisca la frammentazione abbastanza bene. <P> <DT><B>Dimensione</B><DD><P>Difficile a dirsi, piccoli sistemi girano facilmente con appena pochi MB ma questi sono noti posti di nascondiglio per tenere lontano dalla vista di occhi curiosi e dal rinforzo della quota e possono crescere senza controllo su macchine più grandi. Suggerito: piccole macchine casalinghe: 32 MB, piccoli server: 128 MB e grosse macchine fino a 500 MB (la macchina che l'autore usa al lavoro ha 1100 utenti e una <CODE>/tmp</CODE> di 300 MB). Controllate queste directory, non solo per file nascosti ma anche per vecchi file. Preparatevi anche al fatto che queste partizioni potrebbero essere la prima ragione che potreste avere per ridimensionare le vostre partizioni. <P> <DT><B>Affidabilità</B><DD><P>Bassa. Quando queste aree falliscono o si riempiono, spesso i programmi emetteranno un avvertimento, oppure falliranno splendidamente. Errori di file casuali saranno ovviamente più seri, non importa quale area file sia. <P> <DT><B>File</B><DD><P>Generalmente piccoli file ma potrebbe esservene un gran numero. Normalmente i programmi cancellano i loro file <CODE>tmp</CODE> ma se casualmente interviene un'interruzione, possono sopravvivere. Molte distribuzioni hanno una linea di condotta riguardo la pulizia dei file <CODE>tmp</CODE> all'avvio, quindi potreste voler controllare quale sia la vostra configurazione. <P> <DT><B>Nota1</B><DD><P>In FSSTND c'è una nota riguardo al mettere <CODE>/tmp</CODE> su RAM disk. Questo comunque non è consigliato per le stesse ragioni espresse al riguardo dello swap. Inoltre, come segnalato prima, non utilizzate dispositivi flash RAM per queste directory. Ci si dovrebbe ricordare inoltre che qualche sistema è organizzato in modo da pulire automaticamente le aree <CODE>tmp</CODE> al riavvio. <P> <DT><B>Nota2</B><DD><P>I sistemi più vecchi avevano un <CODE>/usr/tmp</CODE> ma questo non è consigliato e, per motivi storici, un link simbolico lo fa puntare ad una delle altre aree <CODE>tmp</CODE>. <P> </DL> <P> <P>(* That was 50 lines, I am home and dry! *) <P> <H3>Aree di Coda (<CODE>/var/spool/news</CODE> e <CODE>/var/spool/mail</CODE>)</H3> <P> <!-- disco!aree di coda --> <DL> <DT><B>Velocità</B><DD><P>Alta, specialmente su grossi server di news. Il trasferimento e la scadenza delle news usano molto il disco e beneficieranno di dischi veloci. Code di stampa: bassa. Considerate RAID0 per le news. <P> <DT><B>Dimensione</B><DD><P>Per i server di news/posta: quanta ve ne potete permettere. Per sistemi ad utente singolo pochi MB saranno sufficienti se leggete in continuazione. Iscriversi ad un list server e prendersi una vacanza, non è proprio una buona idea (ancora, la macchina che uso al lavoro ha 100 MB riservati per l'intera <CODE>/var/spool</CODE>). <P> <DT><B>Affidabilità</B><DD><P>Posta: molto alta, news: media, coda di stampa: bassa. Se la vostra posta è molto importante (non lo è forse sempre?) considerate RAID per l'affidabilità. <P> <DT><B>File</B><DD><P>Generalmente una grande quantità di file che in dimensione sono intorno a pochi KB. I file nella coda di stampa, possono d'altra parte essere pochi ma abbastanza grandi. <P> <DT><B>Nota</B><DD><P>Qualche documentazione sulle news, suggerisce di mettere tutti i file <CODE>.overview</CODE> su un disco separato dai file delle news, controllate tutte le FAQ sulle news per più informazioni. La dimensione tipica è di circa il 3-10 per cento di tutto lo spazio di coda. <P> </DL> <P> <H3><A NAME="home-dirs"></A> Directory Home (<CODE>/home</CODE>) </H3> <P> <!-- disco!directory home --> <DL> <DT><B>Velocità</B><DD><P>Media. Sebbene molti programmi utilizzino <CODE>/tmp</CODE> per archiviare temporaneamente, altri come alcuni lettori di news, aggiornano frequentemente i file nella directory home, il che può essere notato su ampi sistemi multitenti. Per piccoli sistemi, questo non è un problema. <P> <DT><B>Dimensione</B><DD><P>Difficile! Su qualche sistema, la gente paga per archiviare, perciò questo generalmente è una questione di soldi. Grossi sistemi come <A HREF="http://www.nyx.net/">nyx.net</A> (che è un servizio di Internet gratuito con posta, news e servizi WWW) girano con successo con un limite suggerito di 100 KB per utente e 300 KB come massimo applicato. Gli ISP commerciali offrono tipicamente circa 5 MB nei loro pacchetti standard di abbonamento. <P>Se comunque scrivete libri o fate del lavoro grafico, le necessità si gonfiano velocemente. <P> <DT><B>Affidabilità</B><DD><P>Variabile. Perdere <CODE>/home</CODE> su una macchina con un singolo utente è fastidioso ma quando 20000 utenti ti chiamano per dirti che le proprie directory home sono andate è più che fastidioso. Per alcuni, la propria fonte di sostentamento risiede qui. Fate backup regolari ovviamente, no? <P> <DT><B>File</B><DD><P>Ugualmente difficile. Il setup minimo per un singolo utente è di circa una dozzina di file, di dimensione di 0.5 - 5 KB. I file relativi al progetto, possono essere sufficientemente numerosi. <P> <DT><B>Nota1</B><DD><P>Potreste considerare RAID sia per la velocità che per l'affidabilità. Se volete velocità estremamente alta ed affidabilità, dovreste vedere altri sistemi operativi e piattaforme hardware (tolleranza ai guasti ecc.). <P> <DT><B>Nota2</B><DD><P>I navigatori spesso utilizzano una cache locale per aumentare la velocità di navigazione e questa cache può occupare una quantità di spazio sostanziale e causare parecchia attività del disco. Ci sono molti metodi per evitare questi colpi alle prestazioni, per maggiori informazioni guardate 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> <DT><B>Nota3</B><DD><P>Gli utenti spesso tendono ad utilizzare tutto lo spazio disponibile sulla partizione <CODE>/home</CODE>. Il sottosistema Quota di Linux è in grado di limitare il numero di blocchi e il numero di inode che l'ID di un singolo utente può allocare su una base di un filesystem. Guardate il <A HREF="http://metalab.unc.edu/LDP/mini">Linux Quota mini-HOWTO</A> di Albert M.C. Tam <CODE>bertie (at) scn.org</CODE> per i dettagli sull'impostazione. <P> </DL> <P> <P> <H3><A NAME="main-binaries"></A> File binari principali ( <CODE>/usr/bin</CODE> e <CODE>/usr/local/bin</CODE>)</H3> <P> <!-- disco!binari principali --> <DL> <DT><B>Velocità</B><DD><P>Bassa. Spesso i dati sono più grandi dei programmi che sono comunque richiesti su domanda, quindi questo non è rischioso per la velocità. Testimoni i live file system su CD ROM. <P> <DT><B>Dimensione</B><DD><P>Il limite è il cielo ma 200 MB dovrebbero darvi molto di quello di cui avete bisogno per un sistema completo. Un grande sistema, per sviluppo software o un server dai molti fini dovrebbe forse riservare 500MB sia per l'installazione che per la crescita. <P> <DT><B>Affidabilità</B><DD><P>Bassa. è generalmente montato sotto root dove tutti gli essenziali sono raccolti. Tuttavia perdere tutti i file binari fa male... <P> <DT><B>File</B><DD><P>Variabile ma generalmente dell'ordine di 10 - 100 KB. </DL> <P> <P> <H3>Librerie ( <CODE>/usr/lib</CODE> e <CODE>/usr/local/lib</CODE>)</H3> <P> <!-- disco!librerie --> <DL> <DT><B>Velocità</B><DD><P>Media. Questi sono grosse trance di dati caricati spesso, spaziano dai file oggetto ai font, tutti suscettibili di rigonfiamento. Spesso questi sono anche caricati nella loro interezza e la velocità è abbastanza utilizzata qui. <P> <DT><B>Dimensione</B><DD><P>Variabile. Qui, ad esempio, $egrave; dove gli elaboratori di testo archiviano i loro immensi file di font. I pochi da cui ho avuto un feedback su questo, riportano circa 70 MB nelle loro varie directory <CODE>lib</CODE>. Un'installazione abbastanza completa della Debian 1.2, può arrivare a circa 250 MB, che può essere preso come un limite superiore realistico. I seguenti sono alcuni dei più grossi consumatori di spazio su disco: GCC, Emacs, TeX/LaTeX, X11 e perl. <P> <DT><B>Affidabilità</B><DD><P>Bassa. Controllate il punto <A HREF="#main-binaries">File binari principali</A>. <P> <DT><B>File</B><DD><P>Generalmente grossi, di cui molti di dimensioni dell'ordine di 1 MB. <P> <DT><B>Nota</B><DD><P>Per motivi storici, qualche programma tiene gli eseguibili nelle aree lib. Un esempio è GCC che ha grossi file binari nella gerarchia <CODE>/usr/lib/gcc/lib</CODE>. </DL> <P> <H3>Boot</H3> <P> <!-- disco!boot --> <DL> <DT><B>Velocità</B><DD><P>Abbastanza bassa: dopo tutto il boot non avviene così di frequente e caricare il kernel è solo una minima frazione del tempo che si impiega per rendere operativo il sistema. <P> <DT><B>Dimensione</B><DD><P>Abbastanza piccola, un'immagine completa con qualche extra entra in un singolo floppy, così 5 MB dovrebbero essere sufficienti. <P> <DT><B>Affidabilità</B><DD><P>Alta. Guardate la sezione sotto su Root. <P> <DT><B>Nota 1</B><DD><P>La parte più importante riguardo la partizione di boot è che su molti sistemi, <EM>deve</EM> risiedere al di sotto del cilindro 1023. Questa è una limitazione BIOS che Linux non riesce a gestire. </DL> <P> <P> <H3>Root</H3> <P> <!-- disco!root --> <DL> <DT><B>Velocità</B><DD><P>Abbastanza bassa: qui c'è solo il minimo indispensabile, la maggior parte del quale gira solo all'inizio. <P> <DT><B>Dimensione</B><DD><P>Relativamente piccola. In ogni caso è una buona idea mantenere qualche file di recupero e utilità sulla partizione di root e qualcuno ci tiene diverse versioni del kernel. <P> <DT><B>Affidabilità</B><DD><P>Alta. Un fallimento qui causerà probabilmente un gran dolore e potresti finire col perdere del tempo a recuperare la tua partizione di boot. Con un po' di pratica potete naturalmente farlo in un'ora o giù di lì, ma penso che anche se avete un po' di pratica nel farlo, state anche facendo qualcosa di sbagliato. <P>Naturalmente avete un disco di recupero no? Ovviamente questo è stato aggiornato da quando avete fatto l'installazione iniziale? Ci sono molti dischi di recupero già fatti come anche strumenti per la creazione di dischi di recupero che potreste trovare validi. Presumibilmente investire del tempo in questi vi salva dal diventare un esperto nel recupero di root. <P> <DT><B>Nota 1</B><DD><P>Se avete molti dischi, potreste considerare di mettere una partizione boot di emergenza di ricambio su un disco fisico separato. Vi costerà un po' di spazio ma se il vostro setup è molto vasto il tempo risparmiato, nel caso qualcosa fallisse, varrebbe molto lo spazio extra. <P> <DT><B>Nota 2</B><DD><P>Per semplicità e anche nel caso di emergenza non è consigliabile di mettere la partizione root su un sistema RAID a livello 0. Inoltre se utilizzate il RAID per la vostra partizione di boot, dovete ricordare che sia abilitata l'opzione <CODE>md</CODE> per il vostro kernel di emergenza. <P> <DT><B>Nota 3</B><DD><P>Per semplicità è abbastanza comune mantenere Boot e Root sulla stessa partizione. Se fate ciò, allora al fine di fare il boot da LILO, è importante che i file di boot essenziali risiedano tutti entro il cilindro 1023. Questo include il kernel come anche i file che si trovano in <CODE>/boot</CODE>. </DL> <P> <P> <H3>DOS ecc.</H3> <P> <!-- disco!questioni relative al DOS --> A rischio di apparire eretico ho incluso questa piccola sezione riguardo un qualcosa contro cui molti di quelli che leggono questo documento hanno forti sensazioni. Sfortunatamente molti componenti hardware li troviamo con setup e mezzi di mantenimento basati su questi sistemi, quindi ecco qui. <P> <DL> <DT><B>Velocità</B><DD><P>Molto bassa. I sistemi in questione non sono famosi per la velocità, quindi c'è un piccolo appunto sull'utilizzo di dischi di prima qualità. Il multitasking o il multi-threading non sono disponibili, quindi il comando di agevolazione di accodaggio nei dischi SCSI non è una cosa di cui potrete trarre vantaggio. Se avete un vecchio disco IDE sarà sufficientemente buono. L'eccezione è in qualche modo Win95 e ancor di più NT che hanno supporto multi-threading che teoricamente dovrebbe essere in grado di trarre vantaggio delle più avanzate caratteristiche offerte dai dispositivi SCSI. <P> <DT><B>Dimensione</B><DD><P>La compagnia che sta dietro questi sistemi operativi non è famosa per scrivere codice stringato, così dovete essere preparati a spendere poche decine di MB a seconda di quale versione installate del DOS o di Windows. Con una vecchia versione di DOS o Windows potreste fare entrare tutto in 50 MB. <P> <DT><B>Affidabilità</B><DD><P>Ha-ha. Visto che la catena non è più forte dell'anello più debole, potete usare qualsiasi vecchio disco. Dal momento che è più facile che il SO si scombini da solo, piuttosto che il drive si autodistrugga, imparerete presto l'importanza di backup qui. <P>Mettetela in un altro modo: "<I>La vostra missione, se doveste accettarla, è di fare funzionare questa partizione. La garanzia si autodistruggerà tra 10 secondi...</I>" <P>Recentemente mi è stato chiesto di giustificare le mie lamentele in questa sede. Prima di tutto non sto cercando misere scuse per il Dos e Windows come sistemi operativi. Secondariamente ci sono vari articoli legali che devono essere presi in considerazione. Dire che c'è una relazione tra le due ultime frasi è solamente un vaneggiamento paranoide. Di sicuro. Invece offrirò allo stimato lettore un po' di parole chiavi: DOS 4.0, DOS 6.x e vari mezzi di compressione del disco che rimarranno senza nome. <P> </DL> <P> <P> <H2><A NAME="ss4.2">4.2 Spiegazione dei termini</A> </H2> <P> <!-- disco!spiegazione dei termini --> Ovviamente più veloce è meglio è, ma spesso il felice installatore di Linux ha svariati dischi di varia velocità e affidabilità, così anche se questo documento descrive la prestazione come 'veloce' o 'lenta' è solamente una rozza guida dal momento che non è determinabile alcun tipo di precisione più fine. Anche se ci sono dei dettagli che si dovrebbero ricordare: <P> <P> <H3><A NAME="speed"></A> Velocità </H3> <P> <!-- disco!spiegazione dei termini!velocità --> Questa è realmente una confusa commistione di svariati termini: carico della CPU, impostazioni generali del trasferimento, tempo di accesso al disco e velocità di trasferimento. È nella reale natura della regolazione che non c'è un optimum fisso e in molti casi il prezzo è il fattore che fa la differenza. Il carico della CPU è rilevante solo per i sistemi IDE dove è la CPU che esegue da sola il trasferimento, ma è generalmente bassa per lo SCSI, controllate la documentazione SCSI per i valori reali. Anche il tempo di accesso al disco è piccolo, generalmente dell'ordine del millisecondo. Questo comunque non è un problema se usate comandi di accodamento su SCSI, dove sovrapponete comandi mantenendo il bus occupato per tutto il tempo. Gli spool delle news sono un caso speciale consistente in un grande numero di file normalmente piccoli, così in questo caso il tempo di accesso può divenire molto significativo. <P>Ci sono due parametri principali che sono di interesse qui: <P> <DL> <DT><B>L'accesso</B><DD><P>è generalmente definito come il tempo che occorre alla testina di lettura/scrittura per saltare da una traccia ad un'altra. Questo parametro è importante quando si ha a che fare con un grande numero di piccoli file come visto nei file di spool. C'è inoltre l'ulteriore ritardo di accesso prima che il settore desiderato ruoti in posizione sotto la testina. Questo ritardo dipende dalla velocità angolare del disco ed ecco perché a volte questo parametro è riportato per i dischi. I valori comuni sono 4500, 5400 e 7200 RPM (rotazioni al minuto). RPM più alti riducono il tempo di accesso ma ad un costo sostanziale. Inoltre dischi che lavorano a 7200 RPM si sa che sono rumorosi e che generano un grande calore, fattore che dovrebbe essere tenuto in considerazione se state costruendo un grande insieme o una "batteria di dischi". Molto di recente sono entrati nel mercato dischi che lavorano a 10000 RPM e qui le richieste di raffreddamento sono ancora più strette e vengono date pochissime indicazioni per il flusso d'aria. <P> <DT><B>Il trasferimento</B><DD><P>è generalmente espresso in megabyte al secondo. Questo parametro è importante quando si utilizzano grandi file che devono essere trasferiti. I file di libreria, i dizionari e i file di immagine sono un esempio di questo. I dischi che posseggono alta velocità rotazionale, normalmente hanno anche trasferimenti veloci visto che la velocità di trasferimento è proporzionale alla velocità angolare per la stessa densità di settore. </DL> <P>È inoltre importante leggere le specifiche per i dischi molto attentamente e noterete che la massima velocità di trasferimento è spesso riportata intendendo i trasferimenti dalla cache integrata (burst speed) e <EM>non</EM> direttamente dalla superficie del disco (sustained speed). Guardate anche la sezione sull' <A HREF="Multi-Disk-HOWTO-19.html#power-heating">Alimentazione e riscaldamento</A>. <P> <P> <H3>Affidabilità</H3> <P> <!-- disco!spiegazione dei termini!affidabilità --> Naturalmente nessuno vorrebbe dischi con bassa affidabilità ma uno farebbe bene a giudicare vecchi dischi come inaffidabili. Inoltre per scopi RAID (controllate le informazioni pertinenti) è consigliato utilizzare un insieme misto di dischi così che crash simultanei di più dischi possano diventare meno probabili. <P>Fino ad oggi ho avuto notizia di un solo rapporto di fallimento totale del file system, ma qui l'hardware instabile è sembrato essere la causa dei problemi. <P>Anche se i dischi sono economici al giorno d'oggi, la gente ancora sottostima il valore dei contenuti dei dischi. Se avete bisogno di affidabilità più alta, assicuratevi di rimpiazzare i vecchi dischi e mantenete i ricambi. Non è inusuale che i dischi possano lavorare più o meno continuamente per anni ed anni ma ciò che spesso uccide i dischi alla fine sono i cicli di alimentazione. <P> <H3>File</H3> <P> <!-- isco!spiegazione dei termini!file --> La dimensione media dei file è importante al fine di decidere i paramentri del disco più appropriati. Un grande numero di piccoli file fa sì che il tempo di accesso divenga importante, invece per grossi file diventa importante la velocità di trasferimento. Il comando di accodamento nei dispositivi SCSI è molto comodo per maneggiare un grosso numero di piccoli file, ma per il trasferimento l'EIDE non è così lontano dallo SCSI e normalmente molto più economico dello SCSI. <P> <P> <P> <HR> <A HREF="Multi-Disk-HOWTO-5.html">Avanti</A> <A HREF="Multi-Disk-HOWTO-3.html">Indietro</A> <A HREF="Multi-Disk-HOWTO.html#toc4">Indice</A> </BODY> </HTML>
