Windows 10 com média de mais de 50 GB de gravações / dia para SSD ao longo de nove meses

Question

Atualização: Movendo as seguintes pastas para fora da unidade, o link simbólico delas eliminou a gravação constante em C :.

• %LocalAppData%\Google\Chrome - Facilmente o maior consumidor.
• %LocalAppData%\Microsoft\Windows\FileHistory

Eu os movi para uma unidade recém-formatada. Após 3 horas já foram 10.5GB de leituras e 10.3GB de gravações. Nesse mesmo tempo, Drive C: \ viu apenas 3.5GB de leituras e 1.3GB de gravações.

Isso tem me incomodado por um tempo. O Windows 10 Education parece gravar dados constantemente na unidade C: \ sem nenhum motivo aparente, mesmo quando o computador não é utilizado por dias a fio. Não consigo encontrar a fonte das gravações ou os dados que ela grava.

Em apenas 9 meses, 10% da vida útil da unidade Samsung 850Evo de 500GB foi consumida. Isso ocorre porque o Windows está fazendo muitos registros e rastreamento em segundo plano? Se esse é o motivo, gostaria de conselhos sobre como desativá-lo. Eu sinto que não há mais nada que eu poderia sair da unidade C:\ (mais sobre isso no breakdown)

O HWInfo64 executou os últimos 12,75 dias (com 14 dias de atividade) para rastrear as estatísticas da unidade. Durante esse tempo, o PC não foi tocado de 1º de julho a 5 de julho ou 8 de julho. Eu acho que o tempo máximo possível em uso é de cerca de 5 dias porque durante os dias da semana ele fica intocado por pelo menos 18 horas.

Aqui está um resumo da maioria das unidades:

• 500 GB Samsung 850Evo ( Age: 0.7yr | HostWrites: 13.3TB(~50GB/day) )

  • C:\ Nas últimas 2 semanas: Nada de novo instalado, mas 900 GB (64 GB / dia) foi escrito. São 180 GB / dia por 5 dias úteis. ShadowCopy (Restauração do sistema) está definido como 10% e não há FileHistory para esta unidade.

• 500 GB Samsung 850Evo ( Age: 1.7yr | HostWrites: 8.6TB )

  • A:\ Dados importantes e pastas UserProfile são mapeados aqui. Esta é a única unidade com o FileHistory ativado. ShadowCopy (Restauração do sistema) está definido como 15%. Isso já foi uma unidade do Windows 7 C: por cerca de um ano.

• 250 GB Samsung 840Evo ( Age: 3.7yr | HostWrites: 10.5TB ) & 256GB Crucial m4 ( Age: 4.8yr | HostWrites: 25TB )

  • D:\ As unidades são agrupadas para criar um Stripped StorageSpace (raid0). As pastas PageFile, TEMP, SoftwareDistribution, NodeJS / npm, Origin, Steam e Recorded TV são armazenadas aqui. Não há ShadowCopy (Restauração do Sistema) ou FileHistory para esta unidade.
  • No Windows 7, cada unidade era uma unidade do sistema ao mesmo tempo, a 840Evo por um ano e a m4 por 3 anos. O m4 acabou de começar a falhar nos últimos 30 dias e geralmente fica off-line durante gravações pesadas. As estatísticas do HWInfo mostram mesmo que não está pesando. StorageSpaces gerencia a unidade bem o suficiente para que eu não tenha conseguido remover a unidade ainda. Isso ocorre após apenas 25 TB de HostWrites em um período de 5 anos, o 850Evo já está na metade do caminho. Este é o fator motivador por trás dessa questão.

• 4TB HGST Deskstar ( Age: 2.6yr | HostWrites: 17TB ) & 4TB HGST Deskstar ( Age: 0.75yr | HostWrites: 7TB )

  • B:\ & M:\ As unidades são agrupadas para criar um espaço de armazenamento espelhado de 2TB e espelhado de 3TB, respectivamente. Nenhum volume possui proteção FileHistory ou ShadowCopy. Filmes, Música e etc. são armazenados em B:\ n. M:\ é o repositório de suporte para todos os FileHistory com arquivos modificados sendo versionados e copiados para backup a cada 10 minutos.

Como você pode ver, o Windows 7 não escreveu desgaste perto de tantos dados. Aqui está uma captura de tela do HWInfo64.

    

Answer 1

Você pode usar o Gerenciador de Tarefas para ver quais processos estão gravando a maioria dos dados no disco.

Abra Gerenciador de tarefas , selecione a guia Detalhes , clique com o botão direito do mouse no cabeçalho da tabela e clique em Selecionar colunas . Em seguida, verifique bytes de leitura de E / S , bytes de gravação de E / S e outros bytes de E / S e clique em OK .

Dito isso, acho que o histórico de arquivos é o culpado aqui.

Na minha experiência, os bancos de dados do Histórico de Arquivos ( Catalog1.edb e Catalog2.edb ) podem crescer muito ao longo do tempo. Para piorar, eles são reescritos na íntegra toda vez que o histórico é atualizado (a cada 10 minutos, conforme configurado no sistema), e o Windows os descompactará se você usar a compactação NTFS. Isso pode causar grandes quantidades de gravações no disco ao longo do tempo.

Independentemente de quais unidades são cobertas pelo Histórico de arquivos, esses bancos de dados são armazenados em seu perfil de usuário em C:\Users\<username>\AppData\Local\Microsoft\Windows\FileHistory\Configuration . Com um par de bancos de dados de 100 MB, quase 30 GB por dia serão gravados no volume do sistema a 10 minutos por atualização, assumindo que ele grava os dois arquivos todas as vezes.

Minha solução foi usar um ponto de junção. Pare o serviço Histórico de Arquivos, mova a pasta Configuração para outro local onde a resistência à gravação não seja um problema, crie um ponto de junção que aponte para o novo local no lugar do local original da pasta e reinicie o serviço Histórico de Arquivos. Isso deve resolver o problema.

    

Answer 2

O Windows incorporou o sistema de compartilhamento de atualizações para garantir que você tenha desativado.

Settings > Update & Security > Windows Update > Advanced options > Choose how updates are derived.

Verifique também se você não tem o sistema de backup do Windows ativado.

Settings > Update & Security > Backup.