a) Per l'unità di avvio. Se si vuole avviare il sistema operativo dall'unità che ci si accinge a partizionare, sono necessarie:
una partizione primaria;
una o più partizioni di swap;
zero o più partizioni primarie o logiche.
una o più partizioni primarie o logiche;
zero o più partizioni di swap.
La partizione di avvio dovrebbe essere una partizione primaria, non una partizione logica. Questo facilita il ripristino in caso di disastri, ma non è tecnicamente necessario. Deve essere di tipo 0x83 "nativa Linux". Se si usa una versione di lilo antecedente la 21-3 (cioè, degli anni '90), la propria partizione di avvio deve essere contenuta all'interno dei primi 1024 cilindri dell'unità. Tipicamente è necessario solamente che la partizione di avvio contenga l'immagine del kernel.
Se si ha più di una partizione di avvio (da altri SO, per esempio) le si mantenga tutte nei primi 1024 cilindri (tutte le partizioni DOS devono essere all'interno dei primi 1024). Se si sta usando una versione moderna di lilo, o un meccanismo diverso da lilo per caricare il proprio kernel (un disco di avvio, per esempio, o il caricatore di Linux basato su MS-DOS LOADLIN.EXE), la partizione può essere ovunque. Per dettagli, vedere il Large-disk HOWTO.
A meno che non si faccia lo swap verso file (vedere la la Sezione 9.2) è necessaria una partizione swap dedicata. Deve essere di tipo 0x82 "swap Linux". Può essere posizionata ovunque sul disco (ma vedere la la Sezione 4.4.3). Per lo swap può essere usata sia un partizione primaria sia una logica. Su un'unità può esistere più di una partizione di swap. Ne sono permesse 8 in totale (fra tutte le unità). Vedere le note sulla dimensione di swap più sotto (la Sezione 4.4).
Una singola partizione primaria deve essere usata da contenitore (partizione estesa) per le partizioni logiche. La partizione estesa può essere in qualunque punto del disco. Le partizioni logiche devono essere contigue, ma non è necessario che occupino tutta la partizione estesa.
Tutto il proprio file system Linux può andare nella stessa (unica) partizione. Tuttavia, ci sono circostanze in cui potrebbe essere preferibile contenere la crescita di certi file system. Per esempio, se lo spool di posta fosse nella stessa partizione del file system radice e riempisse lo spazio restante nella partizione, il computer praticamente si pianterebbe.
Contiene le directory di spool come quelle per la posta e la stampa. In aggiunta, contiene la directory con i log di errore. Se la propria macchina è un server e sviluppa un errore cronico, i messaggi risultanti possono riempire la partizione. I computer server dovrebbero avere /var in una partizione diversa da /.
Qui si trova la maggior parte degli eseguibili. In aggiunta, l'albero dei sorgenti del kernel è qui, così come molta documentazione.
Alcuni programmi scrivono qui file di dati temporanei. Di norma sono piuttosto piccoli. Tuttavia, se si eseguono compiti molto intensi dal punto di vista del calcolo, come applicazioni scientifiche o di progettazione, potrebbero essere necessarie centinaia di megabyte per brevi periodi di tempo. In questo caso, tenere /tmp in una partizione diversa da /.
Qui si trovano le directory home degli utenti. Se non vengono imposte quote agli utenti, questa dovrebbe essere in una partizione propria.
Qui si trova l'immagine del kernel. Vedere quanto detto sopra per il suo posizionamento in sistemi vecchi.
Con ext2, le decisioni circa il partizionamento dovrebbo essere governate da considerazioni sui backup e sull'evitare la frammentazione esterna la Sezione 10.4 dovuta ai tempi di vita differenti dei file.
I file hanno un tempo di vita. Dopo che un file è stato creato, rimarrà per qualche tempo nel sistema e poi sarà rimosso. Il tempo di vita dei file varia moltissimo sul sistema ed è in parte dipendente dal nome di percorso del file. Per esempio, file in /bin, /sbin, /usr/sbin, /usr/bin e directory simili probabilmente avranno un tempo di vita molto lungo: molti mesi o più. File in /home probabilmente avranno un tempo di vita medio: diverse settimane o giù di lì. File in /var hanno di solito vita breve: quasi nessun file in /var/spool/news rimarrà più a lungo di alcuni giorni, la vita dei file in /var/spool/lpd si misura in minuti o meno.
Per i backup è utile che la dimensione del backup giornaliero sia inferiore alla capacità del singolo supporto di backup. Un backup giornaliero può essere un backup completo o un backup incrementale.
Si può decidere di mantenere le dimensioni delle proprie partizioni piccole abbastanza da essere completamente contenute in un unico supporto di backup (scegliere il backup completo giornaliero). In ogni caso una partizione dovrebbe essere abbastanza piccola da far sì che il suo delta (tutti i file modificati) giornaliero possa essere contenuto in un unico supporto di backup (scegliere il backup incrementale e aspettarsi di cambiare il supporto di backup per il backup completo settimanale/mensile; non è possibile il funzionamento senza supervisione).
La propria strategia di backup dipende da tale decisione.
Quando si pianifica e si compra spazio disco, ricordarsi di accantonare una quantità di denaro sufficiente per il backup! Dati senza backup non valgono nulla! I costi di ricostruzione dei dati sono molto più alti dei costi di backup praticamente per chiunque!
Nell'ottica delle prestazioni è utile tenere file con tempi di vita diversi in partizioni diverse. In questo modo i file con vita breve nella partizione dei messaggi Usenet possono essere fortemente frammentati. Ciò non ha alcun impatto sulle prestazioni della partizione / o /home.
La prassi convenzionale vuole che si crei uno spazio di swap uguale alla quantità di RAM.
Si tenga però a mente che questa è solo una regola empirica. Facilmente si possono immaginare scenari in cui i programmi hanno insiemi di lavoro estremamente grandi o estremamente piccoli (vedere la la Sezione 3.5). Per esempio, un programma di simulazione con un ampio insieme di dati a cui si accede in modo molto casuale non avrebbe nel suo segmento dati quasi nessuna localizzazione preferenziale di riferimenti, perciò il suo insieme di lavoro sarebbe piuttosto grande.
All'opposto, un programma grafico con molti file JPEG aperti contemporaneamente, tutti ridotti ad icona tranne uno, avrebbe un segmento dati molto grande. Le modifiche alle immagini sono però fatte tutte su una singola immagine; non si accede alla maggior parte della memoria occupata dal programma. Lo stesso vale per un elaboratore di testi con molte finestre aperte in cui solo una finestra alla volta è modificata. Questi programmi hanno, se sono progettati correttamente, una alta localizzazione preferenziale dei riferimenti e una loro grande parte può essere mantenuta nello spazio di swap senza un impatto eccessivamente grave sulle prestazioni. Un utente che non chiude mai i programmi una volta che li ha avviati potrebbe volere, per questa stessa ragione, molto spazio di swap.
I server tipicamente sono configurati con più spazio di swap delle loro controparti desktop. Anche se una certa quantità di swap è sufficiente per il suo funzionamento, il server può trovarsi temporaneamente con carichi pesanti che lo portano a spostare pagine in swap ad un ritmo elevato. Alcuni amministratori preferiscono questo al fare andare il server completamente in crash. In questi casi, lo spazio di swap può essere diverse volte la dimensione della RAM.
Attualmente la dimensione massima della partizione di swap dipende dall'architettura. Per i386, m68k, ARM e PowerPC, è "ufficialmente" 2GB. È 128GB su alpha, 1GB su sparc e 3TB su sparc64. Un opteron con kernel 2.6 può scrivere su una partizione di swap di 16 TB. Per i kernel Linux 2.1 e precedenti, il limite è 128MB. La partizione può essere più grande di 128 MB, ma lo spazio in eccesso non viene mai utilizzato. Se si vuole più di 128 MB di swap per un kernel 2.1 o precedente, si devono creare partizioni di swap multiple (massimo 8). Dopo il 2.4, 32 aree di swap sono "ufficialmente" possibili. Per dettagli vedere la la Sezione 9.
Nota a margine: dimensione massima di swap "ufficiale". Con kernel 2.4, il limite è 64 aree di swap con un massimo di 64GB ciascuna, anche se ciò non trova riscontro nella pagina man di mkswap. Con opteron a 64 bit e kernel 2.6, sono permesse 128 aree di swap, ciascuna di 16 giganteschi TB! (Grazie a Peter Chubb per il calcolo).
La risposta breve è: va bene ovunque. Tuttavia, se si è interessati ad ottenere la maggior velocità possibile, ci sono due strategie di base (oltre a comprare più RAM).
Dividere lo spazio di swap su diverse unità o almeno metterlo sull'unità su cui si scrive di meno.
Posizionare ogni partizione di swap nelle tracce più esterne.
Ecco le considerazioni:
Se si ha un disco con molte testine e uno con meno testine che sono identici per ciò che riguarda gli altri parametri, il disco con molte testine sarà più veloce. Leggere dati da testine diverse è veloce, dato che è puramente elettronico. Leggere dati da tracce diverse è lento, dato che comporta uno spostamento fisico della testina.
Ne consegue pertanto che scrivere lo swap su un'unità separata sarà più veloce che non muovere la testina avanti e indietro su un'unità singola.
Posizionamento: i dischi più vecchi hanno lo stesso numero di settori in tutte le tracce. Con tali dischi sarà più veloce mettere lo swap in mezzo al disco, supposto che la testina del disco si muova da una traccia casuale verso l'area di swap.
I dischi più recenti usano lo ZBR (zone bit recording). Hanno più settori nelle tracce esterne. Con un numero costante di rpm, questo porta a ben più alte prestazioni nelle tracce esterne che non in quelle interne. Mettere il proprio spazio di swap nelle tracce veloci. (In generale, cilindri con un numero basso sono associati a partizioni con numero basso. Comunque vedere i più recenti commenti di Kristian sull'argomento - Tony).
Uso: naturalmente la testina del disco non si muoverà in modo casuale. Se lo spazio di swap è nel mezzo del disco tra una partizione home costantemente attiva e una quasi inutilizzata partizione di archiviazione, sarebbe meglio se l'area di swap fosse vicino alla partizione home per avere movimenti ancora più brevi della testina. Sarebbe però ancora meglio avere lo swap in un altro disco, altrimenti inutilizzato.
Striping: la velocità può essere aumentata scrivendo su aree multiple di swap simultaneamente. Gli spazi di swap con la stessa priorità verranno scritti come in un RAID. Vedere la la Sezione 9.3.
Sintesi: mettere lo spazio di swap su un disco veloce con molte testine che non sia occupato a fare altro. Se si hanno dischi multipli: dividere lo swap e spargerlo su tutti i dischi o perfino su controller diversi.