Vender particionamento para mim

Eu sempre me perguntei por que existe uma paixão por particionar unidades, especialmente em sistemas operacionais Unixy (/ usr, / var, et al). Este não parece ser um tema comum nas instalações do Windows.

Parece que o particionamento aumenta muito a probabilidade de preencher uma partição enquanto outras têm bastante espaço livre. Obviamente, isso pode ser evitado por um design e planejamento cuidadosos, mas as coisas podem mudar. Eu já experimentei isso em máquinas muitas vezes, principalmente em configurações de outras pessoas ou nas configurações de instalação padrão do sistema operacional em questão.

Outro argumento que ouvi é que simplifica o backup. Como isso simplifica o backup? Também ouvi dizer que isso melhora a confiabilidade. Novamente, como?

Quase 100% dos problemas que encontrei no armazenamento em disco estão na falha física do disco. Pode-se argumentar que o particionamento pode potencialmente acelerar a falha de hardware, devido ao desgaste do disco ao mover ou copiar dados de uma partição para outra no mesmo disco?

Não estou tentando balançar muito o barco, gostaria apenas de ver justificativa para uma prática administrativa antiga.

• Fsck mais rápido. Digamos que seu sistema falhe, por algum motivo e quando ele é reiniciado, ele precisa executar um fsck. Com uma partição muito grande, o fsck pode levar uma eternidade e nada no sistema funcionará até que o fsck de todo o sistema esteja pronto. Se você particionar o sistema para que a partição raiz seja bastante pequena, poderá conseguir instalar o sistema e alguns dos serviços básicos em execução enquanto aguarda a conclusão do fsck dos volumes maiores.
  • se o seu sistema tiver unidades pequenas ou houver apenas um serviço no sistema, isso poderá não ser realmente importante.
  • Com sistemas de arquivos com registro em diário, isso pode não importar a maior parte do tempo, mas ocasionalmente, mesmo com um sistema de arquivos com registro em diário, você precisa executar um fsck completo.
• Segurança aprimorada porque você pode montar um fs somente leitura.
  • Por exemplo, ninguém deve precisar escrever para / usr durante o uso normal. Então, por que não montar o sistema de arquivos para que ele seja somente leitura? Ter sistemas de arquivos somente leitura, quando não precisam ser gravados, impedirá alguns ataques de script-kiddy e pode impedir que você destrua coisas quando não quiser.
  • Isso pode dificultar a manutenção do sistema, pois você precisará montá-lo novamente como leitura / gravação quando aplicar atualizações.
• Melhor desempenho, funcionalidade para um serviço / uso específico.
  • Alguns sistemas de arquivos são mais apropriados para serviços / aplicativos específicos, ou permitem que você configure o sistema de arquivos para que ele funcione melhor em alguns casos. Talvez você tenha um sistema de arquivos com muitos arquivos pequenos e precise de mais inodes. Ou talvez você precise armazenar alguns arquivos grandes, imagens de disco virtual.

Eu não acho que configurar muitas partições é algo que você deve fazer para cada sistema. Pessoalmente, na maioria dos servidores Linux, acabei de configurar uma grande partição. Como a maioria dos meus sistemas possui unidades pequenas e tem um único objetivo e atende a algumas funções de infraestrutura (dns, dhcp, firewall, roteador etc.). Nos meus servidores de arquivos, configuro partições para separar os dados do sistema.

Pode-se argumentar que o particionamento pode potencialmente acelerar a falha de hardware, devido ao desgaste do disco ao mover ou copiar dados de uma partição para outra no mesmo disco?

Duvido muito que um sistema bem particionado tenha qualquer probabilidade maior de falha.

Um motivo para manter / home / separado é que você pode reinstalar o sistema operacional e nunca se preocupar com a perda de dados do usuário. Além disso, há muita segurança na montagem de tudo, somente leitura ou noexec. Se os usuários não puderem executar código em qualquer lugar em que possam escrever código, é um vetor a menos de ataque.

Só me incomodaria com isso em uma máquina pública, pois a desvantagem de ficar sem espaço em disco em uma partição, mas tê-lo em outra é um sério aborrecimento. Existem maneiras de contornar isso, como fazer uma invasão de software ou ZFS, em que você poderá redimensionar dinamicamente partições facilmente, mas não tenho experiência com elas.

• Simplificando o backup

Você pode fazer backups (via dumpfs ou similar) do que você deseja, não do que não. O dump (1) é um sistema de backup melhor que o tar (1).

• Preenchendo Partições

Esse é um argumento para particionar também. Os usuários que preenchem seus homedirs não destroem o servidor, derrubam o servidor da web, impedem que os logs aconteçam, impedem que o root efetue login, etc.

Ele também permite que você mova de maneira mais transparente uma seção de seus dados (por exemplo, / home) para outro disco: copie-o, monte-o. Se você estiver usando algo que permita cópias de sombra / instantâneos / o que for, pode fazer isso ao vivo.

Eu sempre fui ensinado a manter / var em uma partição separada, portanto, se você obtiver um arquivo de log fora de controle, entupirá uma única partição e não a unidade inteira. Se ele estiver no mesmo espaço que o resto do sistema e você encher 100% de todo o disco, ele poderá travar e causar uma restauração desagradável.

Todos os argumentos apresentados por Zoredache são válidos; pode-se discutir um pouco os detalhes (ter uma máquina funcionando mais rápido para que você possa fazer outras coisas enquanto furar outros sistemas de arquivos não é muito bom se a razão de existir do sistema em primeiro lugar for nos outros sistemas de arquivos) ; no entanto, todos eles são um pouco de justificativa após o fato.

Na época realmente antiga, você não tinha sistemas de arquivos em partições separadas - você os tinha em discos separados, porque os discos eram realmente pequenos. Pense em 10 MB. (1) Então você tinha uma pequena partição /, um disco / var, um disco / usr, um disco / tmp e um disco / home. Se você precisava de mais espaço, comprou outro disco.

Então, discos "grandes" de 50 MB começaram a custar menos do que o programa moon e, de repente, tornou-se possível colocar um sistema inteiro em um disco com uma quantidade útil de espaço do usuário.

Ainda assim, com os tamanhos de disco pequenos em comparação com o que era possível para o computador gerar, isolar / var e / opt e / home para que o preenchimento de um não derrubasse o computador ainda era uma boa idéia.

Hoje, em uma situação corporativa, não particiono os sistemas operacionais. Os dados são particionados, especialmente se forem gerados pelo usuário; mas frequentemente é porque está em matrizes de disco de alta velocidade e / ou redundantes de algum tipo. No entanto, / var e / usr vivem na mesma partição que /.

Em um ambiente doméstico, a mesma coisa - / home provavelmente deve estar em um disco / matriz separado, para que você possa instalar / atualizar / interromper / consertar quaisquer tipos de SO desejados.

A razão para isso é porque, não importa quão grande você adivinhe o seu / var ou / usr ou qualquer árvore que possa ficar - você estará hilariamente errado ou cometerá um ridículo demais. Um dos meus antigos colegas de escola jura particionando, e sempre fico triste quando ele acaba sentando em um fsck de 180 dias em um sistema que eu criei. Mas posso contar com uma mão durante toda a minha carreira o número de vezes que algo foi preenchido / desativado, enquanto posso contar uma mão o número de vezes até agora este ano em que estive olhando para um sistema em que alguém está decidi / var nunca precisaria ter mais do que (digamos) 1 GB e estava errado, deixando-me olhando para um / var e '00s de GB grátis em outro lugar do sistema, todos os quais poderiam estar na lua para todos o bem que eles me fazem.

No mundo atual de grandes discos, não vejo motivo real para particionar a árvore do sistema operacional. Dados do usuário, sim. Mas separar partições para / var e / usr e / var / spool etc etc etc etc? Não.

(1) = e eu sei que apenas escolhendo esse tamanho, vou chamar alguém nos comentários dizendo 10 MB? Luxo. Por que nossos discos eram meramente ...

Em resposta a :

Parece que o particionamento aumenta muito a probabilidade de preencher uma partição enquanto outras têm bastante espaço livre.

Em uma máquina Linux, o LVM (gerenciamento de volume lógico) é usado para evitar isso. A maioria dos sistemas de arquivos permite redimensionar (alguns até online). Crio partições diferentes para diferentes usos e as formato para diferentes sistemas de arquivos (por exemplo: xfs para arquivos grandes de download que posso excluir rapidamente). Preciso de mais espaço? Monte uma nova unidade, mova os dados para ela e monte-a onde costumavam estar os dados. É totalmente transparente para usuários e aplicativos.

Com o LVM, você pode adicionar discos ou partições ao grupo de volumes e criar volumes lógicos nesse grupo. Se você deixar espaço livre no grupo de volumes, poderá aumentar as partições que estão sendo preenchidas. Se o sistema de arquivos o suportar (ext3, ext4, reiserfs), você poderá reduzir uma partição que você alocou em excesso.

Por exemplo: faça uma partição de inicialização em / dev / sda1 faça uma segunda partição (não formatada) / 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 você precisar de mais espaço em / downloads (enquanto o sistema de arquivos estiver montado):

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

E agora você tem uma partição de download de 150 GB. Semelhante para casa. Na verdade, acabei de redimensionar uma "partição" ext4 lvm hoje. Por outro lado, volumes lógicos não são realmente partições e o que você diz sobre partições de tamanho errado combina com minha experiência pessoal (mais problemas do que valem).

O esquema tradicional de particionamento do Unix é definitivamente uma prática da velha escola que não é tão útil quanto antes. No dia em que o tempo de atividade do sistema Unix era medido em anos, e você tinha dezenas de centenas de usuários brincando com shells, montar / usr como somente leitura era uma maneira útil de proteger o sistema. Agora, a remontagem de sistemas de arquivos para corrigir parece mais trabalhosa e pouco útil.

Na minha universidade, nos bons velhos tempos, os clusters do Unix tinham sistemas de arquivos somente leitura com as ferramentas padrão do unix, e os aplicativos complementares estavam em / usr / local, que era um sistema de arquivos NFS e mais tarde um AFS. Parte disso era a conveniência ... quem queria recompilar o software em uma dúzia de caixas no cluster quando era possível executar aplicativos em uma rede de alta velocidade, 4 Mb ou 10 Mb? Hoje, com gerentes de pacotes decentes e muito disco barato, não é nada demais.

Acho que os processos de pensamento começaram a mudar para mim nas caixas da Sun com o Veritas Volume Manager por volta de 1999, o que reduziu consideravelmente o limiar de dor na movimentação de discos.

Hoje, quando penso em particionamento, estou pensando em termos de proteção e desempenho de dados. Exemplo ilustrativo:

• A SAN de camada 1 é muito rápida, muito disponível (5 9s), replicada e muito cara. Bancos de dados de missão crítica ou logs de transações moram lá.
• SAN de camada 2 é rápido, disponível (4 9s), caro. Os aplicativos ou dados de prioridade mais baixa estão aqui.
• SAN de nível 3 está disponível (4 9's), barato. Coisas que não são sensíveis ao desempenho vivem lá.

Essas considerações também se aplicam ao Windows. Temos um servidor SCCM que gerencia cerca de 40 mil clientes. O banco de dados e os logs estão no disco IBM DS8000 de mega-buck. Os pacotes de software estão em um EMC Celerra com discos SATA grandes e lentos que custam 60% menos por GB.

Eu entendo que esta pergunta não é específica do sistema operacional, certo?

No Windows, costumo dar a todas as minhas máquinas o mínimo de partições possível, mas não menos que duas - SYSTEM e DATA. Se a máquina tiver dois discos físicos, um (menor) será SYSTEM, o outro DATA. Se houver apenas um disco, divido-o em duas partições.

O motivo disso é apenas um - quando eu precisar reinstalar a máquina (e haverá um tempo), não preciso me preocupar com o conteúdo da partição SYSTEM - apenas faço um formato completo nela e instalação limpa. É claro que isso significa que meus documentos (e de preferência também a área de trabalho) precisam ser mapeados para uma pasta no DATA, mas isso é fácil, especialmente no Vista e em versões posteriores.

Eu também tentei fazer mais partições (como JOGOS, MÚSICA, FILMES etc.), mas isso resultou apenas em algumas delas transbordando em outras, criando mais confusão do que ordem.

(Supondo que um único disco grande esteja disponível), coloquei homee varparticionei partições para controlar o problema "fora de controle [arquivo de log do usuário] preenchendo todo o espaço" e para permitir atualizações fáceis do sistema operacional sem tocar em casa, mas deixe o descansem juntos.

No hardware antigo, era necessário, em algum momento, uma bootpartição separada para garantir que a imagem do kernel estivesse acessível ao gerenciador de inicialização.

Você menciona um preenchimento de disco enquanto o outro tem espaço livre - esse é um dos motivos pelos quais particiono - porque posso garantir que determinadas partições não sejam preenchidas. Embora, da maneira como as cotas eram gerenciadas, você teria que atribuir a todos os usuários uma cota 0 nas outras partições, apenas para garantir que eles não comecem a ocultar os arquivos se conseguirem encontrar um diretório que poderia escrever para.

Quanto à simplificação do backup - se eu souber qual será o tamanho máximo de cada partição, posso ter certeza de que é um tamanho que se encaixa perfeitamente em uma única fita e pode ser concluído em um período fixo de tempo.

Quanto à confiabilidade, a única coisa em que consigo pensar é em monitorar - posso ver mais facilmente quando uma determinada partição está crescendo mais do que deveria e me dá motivos para investigá-la.

... agora, tudo isso dito, estamos longe dos dias em que cada usuário recebe uma pequena cota de 20 MB em uma máquina compartilhada. Alguns dos velhos hábitos não fazem sentido - mas quando você tem um processo que enlouquece e preenche / var, que por sua vez enche / e as coisas param, não é tão ruim de proteção nas máquinas de produção .

Em casa, tenho partições, mas é apenas para facilitar o gerenciamento dos sistemas operacionais instalados.

Pessoalmente, só uso particionamento nos computadores dos meus filhos. Crio uma partição grande para o sistema operacional e uma pequena partição para uma imagem da partição do sistema operacional, para que, quando a máquina for acionada, eu possa restaurá-la rapidamente a partir da imagem.

Em um ambiente corporativo, nunca ouvi um argumento convincente para particionar.

Tudo com moderação é uma coisa boa - pode ser uma boa ferramenta para isolar problemas quando houver uma falha - como o preenchimento do disco ou a corrupção do sistema de arquivos.

Não confunda com falhas de hardware - elas devem ser tratadas por redundância de hardware (RAID)

Dito isto, os sistemas de arquivos hoje em dia falham com menos frequência - algumas até fazem verificações de integridade online (como o ZFS). Espero que o fsck offline desapareça em algum momento ...

Por outro lado, o excesso de execução significa apenas mais trabalho (para você e sua equipe) no final - faça-o com moderação e quando fizer sentido ...