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 ha creato confusione e la compatibilità è stata mantenuta usando collegamenti simbolici il che ha fatto ancora più confusione e la struttura è finita col sembrare un labirinto.
Nel caso di Linux, uno standard chiamato il File Systems Standard (FSSTND) fu fortunatamente accettato all'inizio e oggi è utilizzato dalle maggiori distribuzioni Linux.
Più tardi, venne deciso di creare un successore che supportasse anche altri sistemi operativi oltre al solo Linux e venne chiamato Filesystem Hierarchy Standard (FHS) attualmente alla versione 2.1. Questo standard è in continua evoluzione e sarà quanto prima adottato dalle distribuzioni Linux.
Vi consiglio di non svolgere 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 FHS.
Questo HOWTO si sforza di conformarsi al FSSTND e perseguirà il FHS quando le distribuzioni saranno disponibili.
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 /var/spool/mail è una cosa abbastanza differente.
Ecco un sommario veloce di alcune parti essenziali e delle loro
proprietà e necessità. Badate che questa è solamente una guida
e ci potrebbero essere file binari nelle directory etc e
lib, librerie nelle directory bin e così via.
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.
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.
(Si sa che l'autore prende tazze di tè abbastanza potenti...)
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.
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.
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.
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.
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.
Nel man 8 mkswap 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.
Media. Quando fallisce sapete lo fa rapidamente e il fallimento vi costerà qualche perdita di lavoro. Salvate spesso, no?
Linux offre la possibilità di distribuire lo swapping
su più dispositivi, una caratteristica che vi può far guadagnare
parecchio. Controllate "man 8 swapon" per maggiori dettagli.
Tuttavia, il guadagno di utilizzare un disco RAID per lo swap potrebbe
essere vanificato dalla maggiore pesantezza del codice di RAID.
Perciò il file /etc/fstab potrebbe somigliare a questo:
/dev/sda1 swap swap pri=1 0 0
/dev/sdc1 swap swap pri=1 0 0
fstab è molto sensibile alla
formattazione utilizzata, leggete le pagine man attentamente e non
fate un semplice taglia ed incolla delle linee qui sopra.
Qualcuno utilizza un RAM disk per swappare o qualche altro file system. In ogni caso, se non avete necessità inusuali o setup, difficilmente trarrete vantaggio da questo e questo porta ad usare la memoria a disposizione per le operazioni di cache e buffer.
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 le ultime 64 MB di RAM come swap basato su RAMdisk o come altro supporto di memorizzazione temporaneo.
/tmp e /var/tmp)
Molto alta. Su un disco/partizione separati questo generalmente
ridurrà la frammentazione, sebbene ext2fs gestisca la
frammentazione abbastanza bene.
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 /tmp di 300 MB). Controllate queste directory,
non solo per file nascosti ma anche per vecchi file. Preparatevi anche
che queste partizioni potrebbero essere la prima ragione che potreste avere
per ridimensionare le vostre partizioni.
Bassa. Spesso programmi emetteranno un avvertimento o falliranno splendidamente, quando queste aree falliscono o si riempiono. Errori di file casuali saranno ovviamente più seri, non importa quale area file sia.
Generalmente piccoli file ma potrebbe esservene un gran numero.
Normalmente i programmi cancellano i loro file tmp ma se
casualmente interviene un'interruzione, possono sopravvivere. Molte
distribuzioni hanno una linea di condotta riguardo la pulizia dei file
tmp all'avvio, quindi potreste voler controllare quale sia
il vostro setup.
In FSSTND c'è una nota riguardo al mettere /tmp 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 tmp al riavvio.
I sistemi più vecchi avevano un /usr/tmp ma questo
non è consigliato e per motivi storici, un link simbolico lo fa puntare
ad una delle altre aree tmp.
(* That was 50 lines, I am home and dry! *)
/var/spool/news e /var/spool/mail)
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.
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 riservato per l'intera /var/spool).
Posta: molto alta, news: media, coda di stampa: bassa. Se la vostra posta è molto importante (non lo è forse sempre?) considerate RAID per l'affidabilità.
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.
Qualche documentazione sulle news, suggerisce di mettere
tutti i file .overview 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.
/home)
Media. Sebbene molti programmi utilizzino /tmp
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.
Difficile! Su qualche sistema, la gente paga per archiviare, perciò questo generalmente è una questione di soldi. Grossi sistemi come nyx.net (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.
Se comunque scrivete libri o fate del lavoro grafico, le necessità si gonfiano velocemente.
Variabile. Perdere /home 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?
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.
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 di errore ecc.)
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 alla prestazione, per maggiori informazioni guardate le sezioni sulle Directory Home e WWW.
Gli utenti spesso tendono ad utilizzare tutto lo spazio
disponibile sulla partizione /home. 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
Linux Quota mini-HOWTO di
Albert M.C. Tam bertie (at) scn.org
per i dettagli sull'impostazione.
/usr/bin e /usr/local/bin)
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 systems su CD ROM.
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.
Bassa. è generalmente montato sotto root dove tutti gli essenziali sono raccolti. Tuttavia perdere tutti i file binari fa male...
Variabile ma generalmente dell'ordine di 10 - 100 KB.
/usr/lib e /usr/local/lib)
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.
Variabile. Questo è, ad esempio 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 lib. 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.
Bassa. Controllate il punto File binari principali.
Generalmente grossi di cui molti dell'ordine di 1 MB in dimensione.
Per motivi storici, qualche programma tiene gli eseguibili
nelle aree lib. Un esempio è GCC che ha grossi file binari nella gerarchia
/usr/lib/gcc/lib.
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.
Abbastanza piccola, un'immagine completa con qualche extra entra in un singolo floppy, così 5 MB dovrebbe essere sufficiente.
Alta. Guardate la sezione sotto su Root.
La parte più importante riguardo la partizione di boot è che su molti sistemi, deve risiedere al di sotto del cilindro 1023. Questa è una limitazione BIOS che Linux non riesce a gestire.
Abbastanza bassa: qui c'è solo il minimo indispensabile, la maggior parte del quale gira solo all'inizio.
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.
Alta. Un fallimento qui causerà probabilmente un gran dolore e potresti finire nello spendere 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.
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.
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.
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 md per il vostro
kernel di emergenza.
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 /boot.
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.
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.
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.
Ha-ha. Visto che la catena non è più forte del legame più debole, potete usare qualsiasi vecchio disco. Dal momento che il SO è più facile che si scombini da solo piuttosto che il drive si autodistrugga, imparerete presto l'importanza di backup qui.
Mettetela in un altro modo: "La vostra missione, se doveste accettarla, è di fare funzionare questa partizione. La garanzia si autodistruggerà in 10 secondi..."
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.
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 guida rozza dal momento che non è determinabile alcun tipo di precisione più fine. Anche se ci sono dei dettagli che si dovrebbero ricordare:
Questo è 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 nell'ambito 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.
Ci sono due parametri principali che sono di interesse qui:
è 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.
è 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.
È 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 non direttamente dalla superficie del disco (sustained speed). Guardate anche la sezione sull' Alimentazione e riscaldamento.
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.
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.
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.
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.