Vendi il partizionamento per me

Mi sono spesso chiesto perché ci sia una tale passione per il partizionamento delle unità, in particolare sui sistemi operativi Unixy (/ usr, / var, et al). Questo non sembra essere un tema comune con le installazioni di Windows.

Sembra che il partizionamento aumenti notevolmente la probabilità di riempire una partizione mentre altre hanno molto spazio libero. Ovviamente ciò può essere prevenuto con un'attenta progettazione e pianificazione, ma le cose possono cambiare. L'ho sperimentato molte volte su macchine, principalmente su quelle configurate da altri o dalle impostazioni di installazione predefinite del sistema operativo in questione.

Un altro argomento che ho sentito è che semplifica il backup. Come semplifica il backup? Ho anche sentito che migliora l'affidabilità. Ancora una volta, come?

Quasi il 100% dei problemi che ho riscontrato con l'archiviazione su disco è dovuto a un errore fisico del disco. Si potrebbe sostenere che il partizionamento può potenzialmente accelerare l'errore hardware, a causa del thrashing di un disco quando si spostano o copiano dati da una partizione all'altra sullo stesso disco?

Non sto provando a scuotere troppo la barca, vorrei solo vedere la giustificazione per una pratica di amministrazione secolare.

• Più veloce. Diciamo che il tuo sistema non funziona, per qualche motivo e quando si riavvia deve eseguire un fsck. Con una partizione davvero grande che fsck può durare per sempre e nulla sul sistema funzionerà fino a quando non sarà eseguita la fsck dell'intero sistema. Se si partiziona il sistema in modo che la partizione di root sia piuttosto piccola, allora si potrebbe essere in grado di avviare il sistema e alcuni dei servizi di base in esecuzione mentre si attende il completamento del fsck dei volumi più grandi.
  • se il tuo sistema ha unità di piccole dimensioni o c'è solo un servizio sul sistema, questo potrebbe non avere importanza.
  • Con i file system registrati su giornale questo potrebbe non avere importanza per la maggior parte del tempo, ma a volte anche con un file system registrato su giornale è necessario eseguire un fsck completo.
• Sicurezza migliorata perché puoi montare una fs di sola lettura.
  • Ad esempio, nessuno dovrebbe scrivere a / usr durante il normale utilizzo. Quindi perché non montare semplicemente il filesystem in modo che sia di sola lettura. Avere i filesystem in sola lettura quando non è necessario scriverli impedirà alcuni attacchi da script kiddy e potrebbe impedirti di distruggere le cose quando non intendi.
  • Ciò potrebbe rendere più difficile la manutenzione del sistema, poiché sarà necessario rimontarlo come lettura / scrittura quando è necessario applicare gli aggiornamenti.
• Prestazioni, funzionalità migliorate per un servizio / utilizzo specifico.
  • Alcuni filesystem sono più appropriati per servizi / applicazioni specifici, o consentono di configurare il filesystem in modo che funzioni meglio in alcuni casi. Forse hai un filesystem con molti piccoli file e hai bisogno di più inode. O forse è necessario archiviare file di grandi dimensioni, immagini di dischi virtuali.

Non penso che la creazione di molte partizioni sia qualcosa che dovresti fare per ogni sistema. Personalmente, sulla maggior parte dei miei server Linux ho appena installato una grande partizione. Dal momento che la maggior parte dei miei sistemi ha unità di piccole dimensioni e sono monouso e svolgono un ruolo di infrastruttura (DNS, DHCP, firewall, router, ecc.). Sui miei file server creo partizioni di installazione per separare i dati dal sistema.

Si potrebbe sostenere che il partizionamento può potenzialmente accelerare l'errore hardware, a causa del thrashing di un disco quando si spostano o copiano dati da una partizione all'altra sullo stesso disco?

Dubito fortemente che un sistema ben partizionato avrebbe una maggiore probabilità di guasto.

Un motivo per mantenere / home / separato è che puoi reinstallare il sistema operativo e non preoccuparti mai di perdere i dati dell'utente. Oltre a ciò, c'è molta sicurezza nel montare tutto sia in sola lettura, sia in noexec. Se gli utenti non possono eseguire il codice da nessuna parte in cui possono scrivere codice, si tratta di un vettore di attacco in meno.

Mi preoccuperei solo di quello su una macchina pubblica, poiché il rovescio della medaglia di esaurire lo spazio su disco in una partizione, ma averlo in un'altra è un grave fastidio. Esistono modi per aggirare questo problema come fare un raid software o ZFS in cui dovresti essere in grado di ridimensionare dinamicamente facilmente le partizioni, ma non ho esperienza con esse.

• Semplificazione del backup

È possibile eseguire backup (tramite dumpfs o simili) di ciò che si desidera, non di ciò che non si desidera. dump (1) è un sistema di backup migliore di tar (1).

• Riempimento di partizioni

Questo è un argomento anche per il partizionamento. Gli utenti che riempiono i loro homedirs non distruggono il server, non arrestano il web server, impediscono che i log si verifichino, impediscano a root di accedere, ecc.

Ti consente anche di spostare in modo più trasparente una sezione dei tuoi dati (diciamo, / home) su un altro disco: copiali, montali. Se stai usando qualcosa che consente copie shadow / istantanee / qualunque cosa, puoi persino farlo dal vivo.

Mi è sempre stato insegnato a mantenere / var su una partizione separata, quindi se ottieni un file di registro fuori controllo, intaserai una singola partizione non l'intera unità. Se si trova nello stesso spazio del resto del sistema e si riempie al 100% l'intero disco, è possibile che si verifichi un arresto anomalo e un brutto ripristino.

Tutti gli argomenti avanzati da Zoredache sono validi; uno potrebbe cavillare un po 'con i dettagli (avere una macchina più veloce in modo da poter fare altre cose mentre si fottono altri file system non ti fa molto bene se la ragione del sistema per esistere in primo luogo è su quegli altri filesystem) ; tuttavia sono tutti un po 'giustificati dopo il fatto.

Ai tempi della vecchia scuola, non avevi i filesystem su partizioni separate - li avevi su dischi separati, perché i dischi erano davvero piccoli. Pensa a 10 MB. (1) Quindi avevi un minuscolo / partizione, un disco / var, un disco / usr, un disco / tmp e un disco / home. Se hai bisogno di più spazio, hai acquistato un altro disco.

Quindi i "grandi" dischi da 50 MB iniziarono a costare meno del programma lunare e improvvisamente divenne possibile mettere un intero sistema su un disco con una quantità utilizzabile di spazio utente.

Tuttavia, con le dimensioni del disco ridotte rispetto a ciò che è stato possibile generare per il computer, isolare / var e / opt e / home in modo che il riempimento di uno non abbia fatto crollare il computer fosse comunque una buona idea.

Oggi, in una situazione aziendale, non partizionare i sistemi operativi. I dati vengono partizionati, soprattutto se generati dall'utente; ma spesso è perché si trova su array di dischi ad alta velocità e / o ridondanti di qualche tipo. Tuttavia / var e / usr vivono tutti nella stessa partizione di /.

In un ambiente domestico, la stessa cosa - / home dovrebbe probabilmente trovarsi su un disco / array separato, in modo da poter installare / aggiornare / rompere / riparare qualunque tipo di sistema operativo sia desiderato.

La ragione di ciò è perché non importa quanto grande indovini il tuo / var o / usr o qualunque albero possa avere - ti sbaglierai in modo esilarante o commetterai ridicolmente. Uno dei miei vecchi colleghi di scuola bestemmia per il partizionamento, e io provo sempre dolore da lui quando finisce per sedersi attraverso un fsck di 180 giorni su un sistema che ho creato. Ma posso contare su una mano per tutta la mia carriera il numero di volte che qualcosa è stato riempito / e ha fatto cadere il sistema, mentre posso contare una mano il numero di volte finora quest'anno che ho fissato un sistema in cui qualcuno deciso / var non avrebbe mai avuto bisogno di essere più di (diciamo) 1GB e mi sbagliavo, lasciandomi a fissare un full / var e '00 di GB gratuiti altrove sul sistema, che avrebbero potuto essere tutti sulla luna per tutti il bene mi fanno.

Nel mondo odierno di grandi dischi, non vedo che ci sia una vera ragione per partizionare l'albero del sistema operativo. Dati utente, sì. Ma partizioni separate per / var e / usr e / var / spool etc etc etc? No.

(1) = e so solo selezionando quella dimensione, ho intenzione di ottenere qualcuno nei commenti che dice 10 MB? Lusso. Perché i nostri dischi erano semplicemente ...

In risposta a :

Sembra che il partizionamento aumenti notevolmente la probabilità di riempire una partizione mentre altre hanno molto spazio libero.

Su una macchina Linux, LVM (gestione del volume logico) viene utilizzato per impedire ciò. La maggior parte dei filesystem consente il ridimensionamento (alcuni anche online). Creo partizioni diverse per usi diversi e le formatto in diversi filesystem (es .: xfs per file di download di grandi dimensioni che posso eliminare rapidamente). Bisogno di più spazio? Montare una nuova unità, spostare i dati su di essa, quindi montarla dove prima si trovavano. Completamente senza soluzione di continuità per utenti e applicazioni.

Con LVM, è possibile aggiungere dischi o partizioni nel gruppo di volumi, quindi creare volumi logici in quel gruppo. Se si lascia spazio libero nel gruppo di volumi, è quindi possibile far crescere le partizioni che si stanno riempiendo. Se il filesystem lo supporta (ext3, ext4, reiserfs) puoi ridurre una partizione che hai allocato troppo.

Ad esempio: crea una partizione di avvio su / dev / sda1 crea una seconda partizione (non formattata) / dev / sda2

pvcreate /dev/sda2 # add the partition to LVM
vgcreate vg /dev/sda2 # create a volume group with sda2 in it
lvcreate -n root -L5G vg
lvcreate -n home -L10G vg
lvcreate -n downloads -L100G vg

mkfs.ext3 /dev/vg/root
mkfs.ext4 /dev/vg/home
mkfs.xfs /dev/vg/downloads

mount /dev/vg/root /
mount /dev/vg/home /home
mount /dev/vg/downloads /downloads

Quando hai bisogno di più spazio su / download (mentre il filesystem è montato):

lvresize -L+50G /dev/vg/downloads
xfs_growfs /dev/vg/downloads

E ora hai una partizione di download da 150 GB. Simile per la casa. In effetti oggi ho appena ridimensionato una "partizione" di ext4 lvm. D'altra parte, i volumi logici non sono in realtà partizioni e ciò che dici delle partizioni è jives di dimensioni sbagliate con la mia esperienza personale (più problemi di quanti ne valgano).

Il tradizionale schema di partizionamento Unix è sicuramente una pratica vecchia scuola che non è così utile come una volta. Ai tempi in cui il tempo di attività del sistema Unix veniva misurato in anni e c'erano dozzine di centinaia di utenti che si aggiravano con gusci, montare / usr in sola lettura era un modo utile per proteggere il sistema. Ora reinstallare il filesystem sulla patch sembra più laborioso e non così utile.

Nella mia università ai vecchi tempi, i cluster Unix avevano filesystem di sola lettura con gli strumenti unix standard e le applicazioni aggiuntive erano in / usr / local, che era un NFS e successivamente un filesystem AFS. Parte di ciò era la convenienza ... chi voleva ricompilare il software in una dozzina di caselle nel cluster quando si potevano eseguire app su una rete ad alta velocità, 4 Mb o 10 Mb? Oggi, con gestori di pacchetti decenti e un sacco di dischi economici, non è un grosso problema.

Penso che i processi abbiano iniziato a cambiare per me su Sun box con Veritas Volume Manager intorno al 1999, il che ha ridotto considerevolmente la soglia del dolore per lo spostamento dei dischi.

Oggi, quando penso al partizionamento, sto pensando in termini di protezione e prestazioni dei dati. Esempio illustrativo:

• La SAN di livello 1 è molto veloce, molto disponibile (5 9), replicata e molto costosa. I database o i registri delle transazioni strategici vivono lì.
• La SAN di livello 2 è veloce, disponibile (4 9), costosa. Qui si trovano applicazioni o dati con priorità più bassa.
• La SAN di livello 3 è disponibile (4 9), a buon mercato. Roba che non è sensibile alle prestazioni vive lì.

Queste considerazioni si applicano anche a Windows. Abbiamo un server SCCM che gestisce circa 40.000 client. Il database e i registri sono su disco IBM DS8000 mega-buck. I pacchetti software si trovano su una Celerra EMC con dischi SATA grandi e lenti che costano il 60% in meno per GB.

Capisco che questa domanda non è specifica del sistema operativo, giusto?

Sotto Windows, tendo a dare a tutte le mie macchine il minor numero possibile di partizioni, ma non meno di due: SISTEMA e DATI. Se la macchina ha due dischi fisici, uno (più piccolo) sarà SYSTEM, l'altro DATA. Se c'è solo un disco, l'ho diviso in due partizioni.

Il motivo è solo uno: quando devo reinstallare la macchina (e ci sarà un tempo simile), non devo preoccuparmi del contenuto della partizione di SISTEMA - ci faccio solo un formato completo e un installazione pulita. Questo ovviamente significa che i miei documenti (e preferibilmente anche il desktop) devono essere mappati in una cartella su DATA, ma è facile da fare, specialmente su Vista e versioni successive.

Ho anche provato a creare più partizioni (come GIOCHI, MUSICA, FILMATI, ecc.) Ma questo ha portato solo alcuni di loro a traboccare in altri, creando più confusione che ordine.

(Supponendo che sia disponibile un singolo disco di grandi dimensioni), ho inserito homee varsuddiviso in partizioni separate per controllare il problema "fuori controllo [utente | file di registro] riempiendo tutto lo spazio" e per consentire facili aggiornamenti del sistema operativo senza toccare home, ma lasciare il riposare insieme.

Su hardware più vecchio a volte era necessario disporre di una bootpartizione separata per assicurarsi che l'immagine del kernel fosse accessibile al boot loader.

Si menziona il riempimento di un disco mentre l'altro ha spazio libero - questo è uno dei motivi per cui partizionare - perché posso garantire che determinate partizioni non si riempiano. Sebbene, nel modo in cui venivano gestite le quote, avresti dovuto assegnare a tutti gli utenti una quota 0 sulle altre partizioni, solo per assicurarsi che non iniziassero a nascondere i file se riuscivano a trovare una directory potrei scrivere a.

Per quanto riguarda la semplificazione del backup: se so quale sarà la dimensione massima di ciascuna partizione, posso assicurarmi che sia una dimensione che si adatta perfettamente a un singolo nastro e possa essere completata in un determinato periodo di tempo.

Per quanto riguarda l'affidabilità, l'unica cosa a cui riesco a pensare è il monitoraggio: posso vedere più facilmente quando una determinata partizione sta crescendo più di quanto dovrebbe essere e darmi ragione per esaminarla.

... ora, detto tutto ciò, siamo lontani dai giorni in cui ogni utente riceveva una piccola quota di 20 MB su una macchina condivisa. Alcune delle vecchie abitudini non hanno senso - ma quando si ha un processo impazzire e riempire / var, che a sua volta si riempie / e le cose si fermano, non è poi così male la protezione da avere sulle macchine di produzione .

Per la casa, ho delle partizioni, ma è solo per semplificare la gestione dei sistemi operativi installati.

Personalmente uso solo il partizionamento sui computer di mio figlio. Creo una grande partizione per il sistema operativo e una piccola partizione per un'immagine della partizione del sistema operativo in modo che quando la macchina viene spianata posso ripristinarla rapidamente dall'immagine.

In un ambiente aziendale non ho mai sentito un argomento convincente per il partizionamento.

Tutto con moderazione è una buona cosa - può essere un buon strumento per isolare i problemi in caso di errore - come il riempimento del disco o la corruzione del filesystem.

Non confonderlo con guasti hardware: questi dovrebbero essere gestiti dalla ridondanza hardware (RAID)

Detto questo, i filesystem in questi giorni falliscono meno spesso - alcuni addirittura eseguono controlli di integrità online (come ZFS). Quindi si spera che fsck offline scompaia ad un certo punto ...

D'altra parte, fare troppo questo significa solo più lavoro (per te e il tuo team) alla fine - fallo con moderazione e quando ha senso ...