Vagueando, se minhas máquinas estiverem bem ajustadas para SSDs, eu me senti em confusão lendo em toda a web vários capítulos da história ... sem número.
Não vou questionar a necessidade do TRIM porque, como veremos a seguir, embora os padrões no Ubuntu 14.04 estejam desabilitados, foram oferecidas opções para habilitá-lo quando possível, então eu acho que é desejável e eu acredito que um indesejado recurso nunca teria gerado muito para ler.
O que eu entendi (talvez tudo esteja errado, certamente algum está errado): por causa do fraco desempenho no manuseio do kernel via fstab + maneira de descarte comparado ao Windows imediato trim-on-delete, a ativação no Ubuntu foi adiada até Trusty. E mesmo em Trusty, a ativação foi limitada aos fornecedores de Intel e Samsung SSD, se acreditarmos no manual do fstrim-all (um outro capítulo aqui é que havia bugs críticos em alguns firmwares de SSD). fstrim-all [wa | i] é a ferramenta de ajuda do cron que carrega esta limitação e também nos ignora pela necessidade de entender o que um file-system (e FS support for TRIM) e mount-points devem responder a pergunta como "se minhas duas partições / digamos / home estiverem no mesmo SSD, eu tenho que executar fstrim / / home ou fstrim / é suficiente?". all em "dash-all" significa todos pontos de montagem compatíveis (assim como todas marcas com a ajuda de um único -no-modelo parâmetro -check). Esta lista branca limitada (no homem) era (e ainda é) mais conservadora do que o único script do fstrim-all !!! que tem 2 ~ 4 fornecedores mais, que por sua vez é mais restritivo do que o de ext4 (se alguma vez) ou kernel (bem, não poderia ser menor). Hoje alguns dizem que não há mais lista branca. Eles significam em -all e / ou fstrim binário (se alguma vez lá onde aqui) e / ou kernel?
Confusão eu disse: é porque uma das minhas máquinas é um ubuntu certificada com nenhum-não-não-Intel não-OCZ não-Patriot não-SanDisk, onde ao lado do /etc/cron.weekly/fstrim que executa fstrim -tudo eu acho um script trim que ultrapassa todas as limitações do util-linux executando um simples fstrim -v / >> /var/log/trim.log ? Não me lembro de ter feito isso comigo mesmo. Eu realmente removi o genuíno 12.04 e reparticionei da maneira que eu queria, eu reinstalei do Precise std iso e atualizei para o Trusty ou instalei o 14.04 do zero, não me lembro: então isso pode ser um arquivo deixado para trás, ou no segundo caso talvez o instalador mágico de Trusty detectou uma marca / modelo certificada e adicionou este ./ trim ?
Seja como for, estou certo em pensar que minha Dell não cortará duas vezes por semana? Não que eu tenha medo, eu até penso em mv trim ../cron.daily . Você acabou de dizer de outra maneira que o cron.weekly / fstrim nunca executou um ajuste nesta máquina.
Ignorando isso, comprei um Samsung para o antigo laptop da minha esposa ~ há dois anos. Script único lá no cron.weekly = > sem dúvida.
Então na semana passada eu pude colocar minhas mãos em um Crucial M4 de segunda mão para o qual eu clonei o antigo IDE que fez o / para meu desktop ... lá eu acho que o ajuste nunca será executado contanto que eu não copie o% scripttrim do laptop ou não adiciono o parâmetro pretendido no fstrim one. Se eu correr
sudo /etc/cron.weekly/fstrim
echo $?
0
Estranho, não é ?, Crucial não sendo white-list e script fstrim sendo out-of-the-box inalterado. Isso talvez por design de script ou sub-script (sem log nem saída, seja qual for a coisa ou nada é feito).
Certo? Eu deveria fazer isso? Se sim, não pode ser pela mágica única de "Não há mais whitelist" como se diz. Entre as centenas de atualizações do kernel de 3,13 desde que o Trusty nasceu, algumas agora tornam o ~ fstab discard ~ muito mais aconselhável / confiável que o cron one?