Existe uma razão para manter a partição/unidade principal do Windows C: small?

A razão histórica para esta prática está provavelmente enraizada nas propriedades de desempenho dos HDDs magnéticos rotativos. A área em discos giratórios com a maior velocidade de acesso seqüencial são os setores mais externos (próximo ao início do inversor).

Se você usar toda a unidade do sistema operacional, mais cedo ou mais tarde (por meio de atualizações, etc.), os arquivos do sistema operacional estariam espalhados por toda a superfície do disco. Portanto, para garantir que os arquivos do SO fiquem fisicamente na área de disco mais rápida, crie uma pequena partição do sistema no início da unidade e distribua o restante da unidade em quantas partições de dados desejar.

A busca por latência também depende em parte de quão longe as cabeças precisam se mover, de modo que manter todos os pequenos arquivos próximos uns dos outros também tem uma vantagem nas unidades rotacionais.

Esta prática perdeu toda a razão com o advento do armazenamento SSD.

Resposta curta: Não mais.

Na minha experiência (mais de 20 anos de trabalho de administração de TI), a principal razão para esta prática (outros estão listados abaixo) é que os usuários basicamente não confiam no Windows com seus dados e espaço no disco rígido.

O Windows tem sido notoriamente ruim em permanecer estável ao longo do tempo, limpando depois de si mesmo, mantendo a partição do sistema saudável e fornecendo acesso conveniente aos dados do usuário. Assim, os usuários preferiram rejeitar a hierarquia do sistema de arquivos que o Windows forneceu e lançar seus próprios fora dela. A partição do sistema também agia como um gueto para negar ao Windows os meios para causar estragos fora de seus limites.

• Há muitos produtos, incluindo os da Microsoft, que não são desinstalados de forma limpa e/ou causam problemas de compatibilidade e estabilidade (a manifestação mais proeminente são os arquivos de sobra e entradas de registro ao redor e DLL Inferno em todas as suas encarnações). Muitos arquivos criados pelo SO não são limpos posteriormente (logs, atualizações do Windows, etc.), levando o SO a ocupar mais e mais espaço com o passar do tempo. No Windows 95 e mesmo XP era, o conselho chegou até sugerir uma reinstalação limpa do sistema operacional de vez em quando. A reinstalação do sistema operacional exigia a capacidade de garantir a limpeza do sistema operacional e de sua partição (para também limpar quaisquer dados falsos no sistema de arquivos) - impossível sem várias partições. E dividir o disco sem perder dados só é possível com programas especializados (que podem ter suas próprias surpresas desagradáveis, como resgatar e deixar dados em um estado inutilizável ao encontrar um setor ruim). Vários programas de "limpeza" aliviaram o problema, mas a lógica deles, baseada em engenharia reversa e comportamento observado, foram ainda mais propensos a causar um grande defeito que forçaria uma reinstalação (por exemplo, o utilitário RegClean do próprio MS foi cancelado após o Office 2007 lançamento que quebrou suposições sobre o registro que se baseou). O fato de muitos programas terem salvado seus dados em locais arbitrários tornou ainda mais difícil separar os dados do usuário e do sistema operacional, fazendo com que os usuários instalem programas fora da hierarquia do sistema operacional.
  • A Microsoft tentou diversas maneiras de melhorar a estabilidade, com graus variados de sucesso ( shared DLLs , Windows File Protection e seu sucessor TrustedInstaller, Side-by-side subsystem , a separate repositório para módulos .NET com estrutura de armazenamento que evita conflitos de versões e fornecedores ). As versões mais recentes do Windows Installer têm até uma verificação de dependência rudimentar (provavelmente o último gerenciador de pacotes principal em geral usa esse recurso).
  • Em relação à conformidade de software de terceiros com as práticas recomendadas, eles manejaram entre manter a compatibilidade com softwares mal-feitos, mas suficientemente usados ​​(caso contrário, seus usuários não atualizariam para uma nova versão do Windows) - o que leva a uma quantidade espantosa de kludges e soluções alternativas no sistema operacional, incluindo comportamento de API não documentado, atualização de programas de terceiros para corrigir bugs nelese alguns níveis de virtualização de registro e de sistema de arquivos - e entre forçar Fornecedores terceirizados entram em conformidade com medidas como um programa de logotipo de certificação e um programa de assinatura de driver (feito obrigatoriamente a partir do Vista).
• Os dados do usuário que estão sendo enterrados em um longo caminho sob o perfil do usuário tornaram inconveniente procurar e especificar caminhos para ele. Os caminhos também usavam nomes longos , tinham espaços (uma ruína de shells de comando em todos os lugares) e caracteres nacionais (um grande problema para linguagens de programação, exceto os muito recentes que possuem suporte Unicode abrangente) e eram específicos de localidade (!) E inatingível sem winapi access (!!) (matando qualquer esforço de internacionalização em scripts), o que também não ajudou em nada.
  Assim, ter seus dados no diretório raiz de uma unidade separada era visto como uma estrutura de dados mais conveniente do que a fornecida pelo Windows.
  • Isso só foi corrigido em versões muito recentes do Windows. Os próprios caminhos foram corrigidos no Vista, compactando nomes longos, eliminando espaços e nomes localizados. O problema de navegação foi corrigido no Win7 que fornecia entradas do Menu Iniciar para a raiz do perfil do usuário e a maioria dos outros diretórios sob ele e coisas como pastas "Favoritas" persistentes em diálogos de seleção de arquivos, com padrões razoáveis ​​como Downloads, para salvar a necessidade procure por eles a cada vez.
• Ao todo, os esforços da MS deram frutos no final. Consideravelmente desde o Win7, o SO, o software padrão e de terceiros, incluindo utilitários de limpeza, são estáveis ​​e bem comportados e HDs grandes o suficiente para que o sistema operacional não precise de reinstalação durante toda a vida útil de uma estação de trabalho. E a hierarquia de ações é utilizável e acessível o suficiente para realmente aceitá-la e usá-la na prática do dia-a-dia.

Razões secundárias são:

• Os primeiros softwares (sistema de arquivos e suporte a particionamento em BIOS e sistemas operacionais) estavam ficando para trás dos discos rígidos para suportar grandes volumes de dados, o que exigia a divisão de um disco rígido em partes para poder usar toda a sua capacidade.
  • Isso foi principalmente um problema no DOS e no Windows 95. Com o advento do FAT32 (Windows 98) e NTFS (Windows NT 3.1), o problema foi em grande parte resolvido por enquanto.
  • A barreira de 2 TB que emergiu recentemente foi corrigida pela geração recente de sistemas de arquivos ( ext4 e versões recentes do NTFS ), GPT e 4k discos .
• Várias tentativas para otimizar o desempenho. Os discos rígidos rotacionais são ligeiramente (cerca de 1,5 vezes) mais rápidos na leitura de dados de faixas externas (que mapeiam para os setores iniciais) do que os internos, sugerindo a localização de arquivos acessados ​​com frequência, como bibliotecas do SO e arquivo de paginação próximo ao início do disco. .]
  • Como os dados do usuário também são acessados ​​com muita frequência e o reposicionamento da cabeça tem um impacto ainda maior sobre o desempenho, fora de cargas de trabalho muito específicas, a melhoria no uso real é, na melhor das hipóteses, marginal.
• Vários discos físicos. Esta é uma configuração não típica para uma estação de trabalho, uma vez que um HDD moderno geralmente é suficientemente grande por si só e os laptops nem têm espaço para um segundo HDD. A maioria, se não todas, as estações que vi com essa configuração são desktops que (re) usam HDDs antigos que ainda estão operacionais e somam o tamanho necessário - caso contrário, um RAID deve ser usado ou um dos drives deve conter backups e não estar em uso regular.
  • Este é provavelmente o único caso em que se obtém um ganho real de dividir sistemas e dados em volumes separados: como eles estão fisicamente em hardware diferente, eles podem ser acessados ​​em paralelo (a menos que sejam duas unidades PATA no mesmo cabo) e não haja desempenho bater no reposicionamento da cabeça quando alternar entre eles.
    • Para reutilizar a estrutura de diretórios do Windows, normalmente move C:\Users para a unidade de dados. Mover apenas um único perfil ou mesmo apenas Documents, Downloads e Desktop provou ser inferior porque outras partes do perfil e Public também podem crescer descontroladamente (veja a configuração "separar configuração e dados" abaixo).
  • Embora os discos possam ser consolidados em um volume spanned , eu não uso ou recomendo isso porque os volumes dinâmicos são uma tecnologia proprietária com a qual as ferramentas de terceiros têm problemas para trabalhar e porque se qualquer uma das unidades falhar, o volume é perdido.
• Um M.2 SSD + HDD.
  • Nesse caso, eu prefiro usar o SSD apenas como um cache: desta forma, você obtém o benefício de um SSD para toda a sua matriz de dados, em vez de apenas uma parte arbitrária dele, e o que é acelerado é determinado automaticamente pelo que você realmente acesso na prática.
  • Em qualquer caso, esta configuração em um laptop é inferior a apenas um único SSD porque os HDDs também são intolerantes a choques externos e vibrações, que são ocorrências muito reais para laptops.
• Cenários de inicialização dupla. Geralmente, dois sistemas operacionais não podem coexistir em uma única partição. Este é o único cenário que eu conheço que garante várias partições em uma estação de trabalho. E casos de uso para isso são extremamente raros hoje em dia de qualquer maneira, porque toda estação de trabalho agora é poderosa o suficiente para rodar VMs.
• Nos servidores, existem vários outros cenários válidos - mas nenhum deles se aplica ao domínio do Super User.
  • Por exemplo. é possível separar dados persistentes (programas e configurações) da alteração de dados (dados e logs do aplicativo) para evitar que um aplicativo descontrolado viole todo o sistema. Existem também várias necessidades especiais (por exemplo, em um sistema embarcado, os dados persistentes geralmente residem em uma EEPROM enquanto os dados de trabalho em uma unidade RAM). O Filesystem Hierarchy Standard do Linux se presta muito bem a ajustes desse tipo.

Sou desenvolvedor de software, mas também dediquei tempo fazendo trabalho de TI "normal"/back-office. Eu normalmente mantenho o sistema operacional e os aplicativos na unidade C: e meus arquivos pessoais na unidade D :. Estes não precisam necessariamente ser unidades físicas separadas, mas atualmente eu estou usando um SSD relativamente pequeno como o meu "sistema" drive (C :) e um drive de disco "tradicional" (ou seja, com bandejas magnéticas rotativas) como minha "casa" dirigir (D :).

Todos os sistemas de arquivos estão sujeitos a fragmentação. Com SSDs isso é basicamente um não-problema, mas ainda é um problema com unidades de disco tradicionais.

Eu descobri que a fragmentação pode degradar significativamente o desempenho do sistema. Por exemplo, descobri que uma compilação completa de um grande projeto de software melhorou em mais de 50% após a desfragmentação da minha unidade - e a compilação em questão levou a melhor parte de uma hora, então isso foi not uma diferença trivial.

Mantendo meus arquivos pessoais em um volume separado, descobri:

• o volume do sistema não é fragmentado quase tão rapidamente (ou severamente);
• é muito mais rápido desfragmentar os dois volumes separados do que um único volume com tudo o que está nele - cada volume leva de 20% a 25%, desde que o volume combinado o faça.

Eu observei isso em várias gerações de PCs, com várias versões do Windows.

(Como um comentarista apontou, isso também tende a facilitar a realização de backups.)

Devo observar que as ferramentas de desenvolvimento que uso tendem a gerar um grande número de arquivos temporários, o que parece ser um contribuinte significativo para o problema da fragmentação. Portanto, a gravidade desse problema varia de acordo com o software que você usa; você pode não notar a diferença ou o máximo de um. (Mas há outras atividades - por exemplo, composição e edição de vídeo/áudio - que são intensivas em E/S e, dependendo do software usado, podem gerar um grande número de arquivos temporários/intermediários. isso como algo que afeta apenas uma classe de usuários.)

Advertência: com versões mais recentes do Windows (a partir de 8), isso se tornou muito mais difícil, porque as pastas do usuário em um volume diferente de C: não são mais suportadas oficialmente. Posso dizer que não consegui executar uma atualização in-loco do Windows 7 para o Windows 10, mas YMMV (há várias maneiras diferentes de [re] localizar uma pasta de usuário, não sei quais são afetadas) .

Uma observação adicional: se você mantiver dois volumes separados em uma unidade tradicional, convém configurar um arquivo de paginação no volume D :. Pelas razões descritas na resposta da WooShell, isso reduzirá o tempo de busca ao gravar no arquivo de paginação.

Eu costumava fazer algum trabalho de TI, e aqui está o que eu sei e lembro.

No passado, como outros disseram, havia um benefício real em ter uma pequena partição C no início do disco. Mesmo hoje em alguns laptops de baixo custo isso ainda pode ser verdade. Essencialmente, por ter uma partição menor, você tem menos fragmentação e, mantendo-a no início do disco, é melhor procurar e, assim, ler os horários. Isso ainda é válido hoje em dia com laptops (normalmente) e discos rígidos "verdes" mais lentos.

Outro grande benefício que eu ainda uso hoje é ter "data" e "os" em unidades separadas, ou se eu não posso gerenciar essas partições separadas. Não há aumento real de velocidade se estiver usando unidades SSD, ou unidades magnéticas ainda mais rápidas, mas existe uma enorme opção de "conserto fácil" quando o sistema operacional eventualmente se canaliza. Basta trocar a unidade ou re-fantasma dessa partição. Os dados do usuário estão intactos. Quando configurado corretamente, entre uma unidade D: e janelas de reinstalação de "perfis móveis" é um problema não de 5 minutos. Isso faz com que seja um bom passo para uma tecnologia de nível 1.

Quase duas décadas atrás teria sido dominada pela gama do Windows 98 até o XP, incluindo NT4 e 2000 no lado da estação de trabalho/servidor.

Todos os discos rígidos também seriam armazenamento magnético com cabo PATA ou SCSI, pois os SSDs custam mais do que o computador e o SATA não existia.

Como diz a resposta da WooShell, os setores lógicos mais baixos da unidade (fora da Platter) tendem a ser os mais rápidos. Meus drives Velociraptor de 1TB WDC começam com 215MB/s, mas caem para 125MB/s nos setores externos, uma queda de 40%. E essa é uma unidade Platter de unidade de 2,5 ", portanto a maioria das unidades de 3,5" geralmente apresenta uma queda cada vez maior no desempenho, superior a 50% . Este é o principal motivo para manter a partição principal pequena, mas só se aplica onde a partição é pequena em relação ao tamanho da unidade.

A outra razão principal para manter a partição pequena era se você estivesse usando o FAT32 como o sistema de arquivos, que não suportava partições maiores que 32GB. Se você estava usando o NTFS, as partições até 2 TB eram suportadas antes do Windows 2000 e, em seguida, até 256 TB.

Se sua partição era muito pequena em relação à quantidade de dados que seriam gravados, é mais fácil ficar fragmentado e mais difícil de desfragmentar. De você pode simplesmente ficar sem espaço como o que aconteceu com você. Se você tivesse muitos arquivos em relação aos tamanhos de partição e cluster, o gerenciamento da tabela de arquivos poderia ser problemático e poderia afetar o desempenho. Se você estiver usando volumes dinâmicos para redundância, manter os volumes redundantes tão pequenos quanto necessário economizará espaço nos outros discos.

Hoje as coisas são diferentes, o armazenamento do cliente é dominado por SSDs flash ou drives magnéticos acelerados por flash. Geralmente, o armazenamento é abundante e é fácil adicionar mais a uma estação de trabalho, enquanto nos dias do PATA, talvez seja necessário ter apenas uma conexão de unidade não utilizada para dispositivos de armazenamento adicionais.

Então, isso ainda é uma boa ideia ou tem algum benefício? Isso depende dos dados que você mantém e de como você os gerencia. Minha estação de trabalho C: é de apenas 80 GB, mas o computador em si tem mais de 12 TB de armazenamento, distribuídos por várias unidades. Cada partição contém apenas um certo tipo de dados, e o tamanho do cluster corresponde ao tipo de dados e ao tamanho da partição, o que mantém a fragmentação próxima de 0 e impede que a MFT seja excessivamente grande.

O downsize é que há espaço não utilizado, mas o aumento de desempenho mais do que compensa, e se eu quiser mais armazenamento, eu adiciono mais drives. C: contém o sistema operacional e os aplicativos usados ​​com freqüência. P: contém aplicativos menos usados ​​e é um SSD de 128 GB com uma classificação de durabilidade de gravação inferior a C :. T: está em um SLC SSD menor e contém arquivos temporários do sistema operacional e do usuário, incluindo o cache do navegador. Os arquivos de áudio e vídeo são armazenados magneticamente, assim como as imagens de máquinas virtuais, backups e dados arquivados. Geralmente, eles têm tamanhos de clusters de 16 KB ou mais e as leituras/gravações são dominadas pelo acesso sequencial. Eu executo a desfragmentação apenas uma vez por ano em partições com alto volume de gravação, e leva cerca de 10 minutos para fazer todo o sistema.

Meu laptop tem apenas um SSD de 128GB e um caso de uso diferente, então não posso fazer a mesma coisa, mas ainda me separo em 3 partições, C: (80GB so e programs), T: (8GB temp) e F: ( Arquivos do usuário de 24 GB), que faz um bom trabalho de controlar a fragmentação sem desperdiçar espaço, e o laptop será substituído muito antes de eu ficar sem espaço. Também facilita muito o backup, pois F: contém os únicos dados importantes que são alterados regularmente.

Não, não com o Windows e seus principais suítes de software insistindo em ligações com o System: apesar de instalá-los em Programas :. (É uma necessidade institucionalizada da maneira como a maioria dos sistemas operacionais é construída.) Um volume Data: faz sentido, mas uma unidade removível separada para seus dados (ou NAS, ou backups seletivos ou incrementais para uma unidade removível) faz ainda mais sentido.

O particionamento para sistemas com vários sistemas operacionais também faz sentido, mas cada partição força você a selecionar um limite de armazenamento superior rígido. Geralmente é melhor com unidades separadas, mesmo neste caso.

E hoje, as unidades de máquinas virtuais e de nuvem complementam muitas dessas opções.

Eis uma razão, mas não acredito que seja uma razão válida para os computadores de hoje (modernos).

Isso volta ao Windows 95/98 e XT. Ele provavelmente não se aplica ao Vista e mais tarde, mas era uma limitação de hardware, portanto, a execução de um sistema operacional mais novo no hardware antigo ainda teria que lidar com a limitação.

Eu acredito que a limitação era de 2gb, mas poderia ter havido uma limitação de 1gb (ou talvez outras) em um momento anterior.

A questão era (algo assim): a partição BOOT tinha que estar dentro dos primeiros 2GB (talvez 1GB mais cedo) do espaço físico na unidade. Poderia ter sido que 1) o START da partição BOOT tinha que estar dentro dos limites do limite, ou, 2) a partição de inicialização INTEGRAL tinha que estar dentro dos limites do limite. É possível que em vários momentos, cada um desses casos se aplicasse, mas se o número 2 fosse aplicado, provavelmente duraria pouco, então vou assumir que é o número 1.

Então, com # 1, o START da partição BOOT deve estar dentro dos primeiros 2GB de espaço físico. Isso não impediria fazer uma partição grande para o Boot/OS. Mas o problema era dual/multi boot. Se alguma vez parecia ser possível querer dual/multi boot na unidade, tinha de haver espaço disponível abaixo da marca de 2 gb para criar outras partições de arranque na unidade. Como pode não ser conhecido no momento da instalação se a unidade precisaria de outra partição de inicialização, digamos, Linix ou alguma partição inicializável de depuração/resolução de problemas/recuperação, muitas vezes era recomendável (e muitas vezes sem saber por que) instalar em uma pequena "Partição de inicialização do sistema operacional.

Eu estou querendo saber se o seu departamento de TI há décadas estava preocupado com o backup. Como C: é uma partição de inicialização/OS, seria típico usar algum tipo de backup de imagem, mas para uma partição de dados/programas, um backup incremental de arquivo + pasta poderia ser usado. Reduzir o espaço usado na partição C: reduziria o tempo e o espaço necessários para fazer backup de um sistema.

Um comentário sobre meu uso pessoal da partição C :. Eu tenho um sistema multi-boot, incluindo o Win 7 e Win 10 e eu não tenho nenhum sistema operacional na partição C :, apenas os arquivos de inicialização. Eu uso backup de imagem do sistema Windows para Win 7 e Win 10, e backup de imagem do sistema Windows sempre inclui a partição C: (boot), além da partição Win 7 ou Win 10, então este é outro cenário onde reduzir a quantidade de Os dados e programas na partição C: reduzem o tempo e o espaço necessários para um backup de imagem do sistema (ou restauram, se necessário).

Estou deixando esta seção na minha resposta por causa dos comentários abaixo.

Como meu sistema é multi-boot, reinicializar em um SO diferente torna o backup de partições de dados/programas mais simples, já que não há atividade na (s) partição (ões) durante o backup. Eu escrevi um programa de backup simples que faz uma pasta + cópia de arquivo junto com informações de segurança e de nova análise, mas não funciona muito bem para partições Win 7 ou Win 10, então estou usando o backup de imagem do sistema para C; e ganhar 10 partições do sistema operacional.

Há um motivo específico - o uso de instantâneos de volume.

Um instantâneo de volume é um backup da partição inteira. Ao restaurar a partir desse tipo de backup, você reescreve a partição inteira, revertendo efetivamente o sistema para o estado anterior.

Um administrador do sistema pode criar esses instantâneos regularmente em preparação para qualquer tipo de falha de software. Eles podem até armazená-los em outra partição da mesma unidade. É por isso que você deseja que a partição do sistema seja relativamente pequena.

Ao usar esse esquema, os usuários são incentivados a armazenar seus dados na unidade de rede. Em caso de problemas de software, o administrador do sistema pode apenas reverter o sistema para o estado de funcionamento. Isso seria extremamente eficiente em termos de tempo, comparando-se a investigar manualmente as razões do problema e corrigi-las.