Eu sei que já foi perguntado algo semelhante antes, há muitas informações relacionadas à instalação do Windows XP em um SSD.
Eu posso entender que o Windows XP não foi feito para SSD, OK, ele foi lançado bem antes dos SSDs, então não há função de corte e o XP comete muitas gravações no disco.
Depois de toda essa pesquisa e leitura, vejo por que o Windows XP não deve ser instalado em um SSD. Embora algumas pessoas afirmem que os SSDs têm tantos ciclos de gravação que isso não importa, não estou muito convencido disso.
Ao ponto. Eu li um blog que afirmava que, se o seu sistema operacional suporta trim, o que todos fazem hoje em dia, você pode instalar o Windows XP como um convidado da máquina virtual. E para por aí, eles não elaboram sobre isso. Então eu gostaria de perguntar, isso é verdade?
Ou seria melhor encontrar um HDD de 2,5 ", conectá-lo à placa-mãe e apontar o convidado do Windows XP para o HDD?
Caso alguém queira saber por quê. Estou fazendo um trabalho criado no Excel 2010 - com uso intensivo de VBA (sim, criado há muitos anos), e grande parte do código VBA chama a API Win32, criada no Windows XP Pro.
Eu diria que isso é principalmente uma afirmação falsa (quero dizer, pelo fato de que o TRIM será acionado pela exclusão do arquivo feita na imagem de disco da VM). Alguns hipervisores podem traduzir blocos escritos que são totalmente zeros em comandos TRIM, mas a exclusão de arquivos geralmente não aciona o preenchimento de zeros (em vez disso, apenas uma modificação nos metadados do sistema de arquivos). Além disso, tal tradução exigiria o suporte do sistema operacional host. (Acho que é possível com qemu no Linux com o fato de que você pode acionar TRIM parcial em um arquivo com fallocate, mas não tenho tanta certeza de que o Windows tenha recursos semelhantes em sua camada de bloco.)
No entanto, eu diria que não se preocupe muito com o TRIM. Com mecanismos de nivelamento de desgaste nos SSDs modernos, o TRIM provavelmente não é tão importante/crucial como muitos podem pensar.
Em particular no seu caso, o TRIM ativado no sistema host deve garantir que sempre haja uma quantidade abundante de armazenamento não mapeado , a menos que esteja realmente cheio. Como resultado, o nivelamento de desgaste estará em vigor mesmo para as gravações feitas pela VM. Em outras palavras, mesmo a substituição por meio de um LBA mapeado não deve causar uma gravação local na mesma memória nos bastidores. (Quando o LBA é mapeado para alguma outra memória, a memória antiga que foi mapeada será coletada como lixo, já que obviamente os dados nela contidos não são mais considerados "úteis", é por isso que você realmente não precisa do TRIM para todas as sobrescrições. O que o que você realmente precisa é que haja um conjunto de memória não mapeada que permita que o nivelamento de desgaste funcione.)
Se você estiver usando uma unidade dedicada para a VM (independentemente de ser de passagem ou não), considere o provisionamento excessivo - certifique-se de que vários LBAs não estejam mapeados e nunca serão mapeados. Isso pode ser feito criando uma partição que permanecerá não formatada e TRIM. (Você pode TRIM a unidade inteira com antecedência ou apenas TRIM essa partição se ela for criada pelo espaço ganho com a redução de uma existente. Isso pode ser feito no Linux. Certifique-se de
blkdiscardexecutá -lo na unidade/partição correta, pois é apagará os dados nele. ) (Não sei exatamente quanto seria considerado suficiente, mas, a menos que o espaço seja muito apertado, basta fornecer alguns GBs.)Com isso dito, há rumores de que a maior parte dos esforços tem o superprovisionamento implementado nos bastidores de qualquer maneira, então pode não ser necessário reservar ainda mais algum espaço não mapeado.
Isso depende da configuração do seu disco virtual.
Se você estiver usando uma imagem de disco virtual apoiada por um arquivo em SSD, mesmo que o sistema operacional host suporte TRIM, o problema é que a imagem de disco ainda será considerada suja. Do ponto de vista do sistema host, os setores do disco ainda estão ocupados pelo sistema convidado. Portanto, se o convidado não suportar TRIM, as imagens de disco não serão reduzidas se você excluir arquivos no sistema operacional convidado.
O sistema host TRIM substituiria setores, mas o sistema host não saberia TRIM blocos sujos que o convidado não TRIM.
Se o seu disco virtual estiver configurado como uma passagem IDE/SATA, o sistema operacional host não interferirá de forma alguma nessa interface. O sistema operacional convidado seria responsável por qualquer corte que precisasse ser feito.
Os SSDs irão se desgastar. Os SSDs farão o nivelamento de desgaste de qualquer maneira. TRIM é simplesmente um meio de reduzir o desgaste e tornar o nivelamento de desgaste mais eficiente. TRIM é apenas um método, superprovisionando outro. Se formos obrigados a usar um sistema operacional sem corte, poderíamos compensar isso até certo ponto, reservando mais espaço superprovisionado.
O problema é que os SSDs precisam de “blocos livres” para armazenar novos dados. IOW imagine que o LBA 1000 mantém parte de um arquivo, você atualiza o arquivo e agora o SSD precisa encontrar um novo local para o LBA 1000. Ele faz isso encontrando um local livre, grava os novos dados lá e 'mapeia' esse local para LBA 1000. Ele agora sabe que o local previamente mapeado para LBA 1000 pode ser apagado para que se torne parte dos locais livres disponíveis para dados futuros.
APARAR
Agora suponha que excluímos o arquivo que ocupava o LBA 1000. Esta é uma operação no nível do sistema operacional/sistema de arquivos e o SSD não tem como saber que agora pode apagar o local que foi mapeado para o LBA 1000. E é aí que entra o TRIM. um 'comando' que permite ao sistema operacional informar ao SSD "Concluí o LBA 1000" e, assim, o SSD pode agora preparar proativamente o local atribuído ao LBA 1000 para dados futuros.
Sem TRIM
Sem o TRIM, a única maneira de o SSD 'saber' que algo aconteceu com os dados no local mapeado para o LBA 1000 é quando gravarmos nele novamente. Então, no Windows você cria um novo arquivo e ele acaba sendo gravado no LBA 1000, que no que diz respeito ao SO é gratuito (o cluster mapeado para o LBA 1000 é gratuito). À medida que escrevemos novos dados, o SSD mapeia um novo local para o LBA 1000, e o local anterior fica agora disponível para o coletor de lixo que irá apagá-lo e disponibilizá-lo para dados futuros.
Por si só, não há um problema fundamental com o método no TRIM. No entanto, a falta de TRIM nos deixaria com vários pontos que o sistema operacional sabe que estão disponíveis, enquanto o SSD não está.
O problema
E isso pode se tornar um problema: o SSD não pode simplesmente apagar manchas como as chamamos até agora. Ele só pode apagar vários pontos que pertencem ao mesmo bloco de apagamento ao mesmo tempo.
Portanto, pode acontecer que o local no LBA 1000 seja descartado porque o SO exclui dados neste local, enquanto o local no LBA 1001 não é. E se ambos os pontos estiverem no mesmo bloco de apagamento, o fato de o LBA 1001 conter dados válidos, enquanto o LBA 1000 não contém, impede que o LBA 1000 seja apagável. O SSD primeiro teria que mover os dados do LBA 1001 para um local diferente.
IOW, o SSD precisa de espaço para 'respirar', para embaralhar os dados, para consolidar os pontos usados e, portanto, os pontos não utilizados, para que possa apagar os últimos e prepará-los para novos dados. Quanto menos espaço para respirar, mais o SSD terá que embaralhar para consolidar blocos de apagamento livre e blocos de apagamento em uso. Quanto mais embaralhamento, mais desgaste.
Sobre-aprovisionamento
TRIM é um meio de fornecer espaço para respirar ao SSD, o provisionamento excessivo é outro. O excesso de provisionamento significa simplesmente reservar vários pontos. Se tivermos 1000 vagas no LBA e reservarmos 10% delas, sempre teremos 10% de espaço para respirar. O custo é que agora temos apenas 900 pontos LBA disponíveis para o sistema operacional gravar e usar.
Observe que os SSDs reservaram uma porcentagem da capacidade disponível para provisionamento excessivo de qualquer maneira .
Usando SSDs com sistema operacional sem corte
Como o XP não 'TRIM', poderíamos criar mais espaço para respirar, aumentando a quantidade de espaço que reservamos para o SSD fazer seu trabalho. Alguns SSDs vêm com ferramentas para fazer isso (criando um chamado HPA), então essa é uma opção para fazer isso.
Em essência, você pode fazer o mesmo simplesmente deixando algum espaço não particionado no SSD. Então, o que proponho seria algo como:
Basta executá-lo. Nenhuma máquina virtual, não vai ajudar. Não há um grande problema – você nunca é obrigado a usar o TRIM para que uma unidade funcione. Fazer isso é benéfico para o desempenho e ligeiramente benéfico para a longevidade, mas mesmo um SSD moderno e desordenado será mais rápido do que qualquer coisa que o Windows XP já esperava, e mesmo com uma carga de trabalho de desenvolvimento ocupada, duvido que você atinja o limite de TBW da unidade a qualquer momento nos próximos 10 anos. Você precisa mover arquivos grandes ou executar um banco de dados para que o volume de gravação seja uma grande preocupação.
Mas também, a falta de suporte TRIM em seu sistema operacional principal não significa que você nunca poderá TRIM. Você poderia, digamos, uma vez por mês, inicializar um live-USB do Linux, montar sua unidade do Windows (se ainda não fez isso por padrão), executar o comando nele, esperar que ele termine e reinicializar
fstrim. Apenas uma pequena pausa para manutenção de rotina, como costumava ser a execução do Defrag (e, por falar nisso, não execute o Defrag, pois isso piorará as coisas em vez de melhorar).