O que não colocar em um SSD?

Question

Comprei um SSD e vou configurar meu sistema de desktop com uma instalação completamente nova do Linux.

Os SSDs são conhecidos por serem rápidos, mas têm uma desvantagem: o número de gravações (por bloco?) é limitado.

Então estou pensando em quais dados devem estar localizados no SSD e quais na unidade do HDD. Geralmente eu pensei que os dados que mudam com freqüência deveriam ser colocados no HDD e os dados que não mudam com freqüência podem ser colocados no SSD.

• Agora eu li a pergunta , com um cenário semelhante. Nas respostas está escrito: "Unidades SSD são ideais para o espaço de troca ..."

  Por que os SSDs são ideais para o espaço de troca? OK, eu vejo um alto potencial para elevar o desempenho do sistema, mas a troca de dados não muda frequentemente e, portanto, haveria muitas gravações no SSD, resultando em uma vida útil curta do SSD?

• E o diretório / var? O seu conteúdo também não muda com frequência? Não seria uma boa ideia colocá-lo no disco rígido?

• Existe algum outro dado que não deva estar localizado em um SSD?

Answer 1

Se você se preocupar com os ciclos de gravação, não chegará a lugar nenhum.

Você terá dados em seu SSD que mudam frequentemente; sua casa, suas configurações, caches do seu navegador, talvez até bancos de dados (se você usar algum). Todos devem estar no SSD: por que mais você teria um, senão para ganhar velocidade para as coisas que faz com frequência?

O número de gravações pode ser limitado, mas um SSD moderno é muito bom no uso de nivelamento, então você não deve se preocupar muito com isso. O disco está lá para ser gravado; Se você não usá-lo para isso, você pode usá-lo como peso de papel e nunca colocá-lo em seu computador.

Não há dispositivo de armazenamento adequado para o espaço de troca. O swap é lento , mesmo no SSD. Se você precisar trocar o tempo todo, é melhor obter mais RAM de uma forma ou de outra.

Pode ser diferente para o espaço de troca que não é usado para troca, mas para cenários de suspensão para disco. Naturalmente, quanto mais rápido a mídia de armazenamento usada para isso, mais rápido ela irá suspender e acordar novamente.

Pessoalmente, coloco tudo no SSD, exceto os grandes dados estáticos. Um filme, por exemplo, não precisa gastar um espaço caro no SSD, já que o disco rígido é mais rápido o suficiente para reproduzi-lo. Não será mais rápido usar o armazenamento SSD para isso.

Como toda mídia de armazenamento, o SSD falhará em algum momento, independentemente de você usá-lo ou não. Você deve considerá-los tão confiáveis quanto os HDs, o que não é confiável, então você deve fazer backups.

    

Answer 2

Ok, então o objetivo é obter o máximo de ganho possível - Velocidade x preço do hardware substituto (assumindo que um único disco rígido grande e SSD de tamanho médio, o que parece ser a norma). Para simplificar, você pode pesar o quanto você percebe que a velocidade aumenta de mover um arquivo para o SSD em relação ao número de setores gravados para mover esse arquivo para o SSD.

• Arquivos que precisam ser muito lidos e gravados raramente (como o sistema operacional e os programas) provavelmente seriam os mais óbvios para migrar para o SSD.
• Arquivos que são gravados uma vez e lidos muitas vezes em uma taxa fixa de dados onde o HDD é rápido o suficiente (por exemplo, música, vídeo) provavelmente deve ficar lá. Eles geralmente não são modificados, mas considere que eles são escritos para um lote de setores.
• Arquivos pequenos que são muito modificados (como alguns arquivos temporários) são mais complicados. Por exemplo, dado um tamanho de setor de 512 bytes, você pode sobrescrever um arquivo de setor único 20.000.000 de vezes antes de "consumir" a mesma quantia de gravações que gravar um único arquivo de 1 GiB uma vez. Se o SSD cuida do uso do nivelamento , isso deve ser equivalente.

É claro que mesmo os melhores cálculos também usam o recurso mais precioso de todos os tempos. Então, no longo prazo, você provavelmente é melhor mantê-lo simples e comprar um novo hardware um pouco com mais frequência do que o caso absolutamente ideal.

    

Answer 3

Concordando com os outros, você deve colocar praticamente tudo, exceto arquivos de vídeo (grandes), para evitar o desperdício de espaço SSD caro.

No entanto, você também deve garantir que o TRIM esteja ativado:

• Seu SSD suporta TRIM
• Sua partição está alinhada em um múltiplo do EBS
• Seu sistema de arquivos suporta o TRIM no seu sistema de arquivos (geralmente o ext4)
• Você executa fstrim regularmente (provavelmente em um cron semanalmente)
• Você tem pelo menos 25% de espaço livre em disco [ 1 ]

Lembre-se de fazer backup de seus dados.

ATUALIZAÇÃO:

• O Arch recomenda não colocar o swap no SSD para evitar o desgaste

Answer 4

Além de todas as respostas aqui, há uma pequena dica que eu gosto. Eu comecei a usar o ramdisk novamente com meu SSD para diminuir o efeito de usar um pouco. Eu estou usando para um cache de navegador (bem perfil do navegador inteiro), temps / var / log etc. (via links simbólicos)

Meu ramdisk é definido no fstab da seguinte forma:

tmpfs       /mnt/ramdisk tmpfs   nodev,nosuid,size=512M   0 0

Mais RAM você tem ramdisk maior que você pode usar com eficiência. Com isso eu tenho script de boot / shutdown. Várias experiências com a gravação de backup de ramdisk em dispositivo / pasta criptografados, mesmo com prioridade mais baixa na inicialização e mais alta no desligamento.

Isso acelera um pouco o sistema e economiza alguns ciclos de gravação. Ainda bem que pode ser uma tarefa do cron fazendo rsync a cada 15 minutos?

#!/bin/bash

### BEGIN INIT INFO
# Provides:          Ramdisk control
# Required-Start:    $local_fs
# Required-Stop:     $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 6
# Short-Description: Start/stop script at runlevel change.
# Description:       Ramdisk auto backup and restore
### END INIT INFO

PATH=/sbin:/bin:/usr/sbin:/usr/bin
USER="user1"
RDISK=/mnt/ramdisk
BACKUP=/opt/
#/home/$USER/BackUps/

#echo "$(date) $1" >> $BACKUP/rd.log

case "$1" in
    stop)
        rsync -aE --delete $RDISK $BACKUP
        ;;
    start|force-reload|restart|reload)
        #restore ramdisk
        cp -rp $BACKUP/ramdisk/* $RDISK 2> /dev/null
        ;;
    *)
        echo 'Usage: /etc/init.d/ramdisk {start|reload|restart|force-reload|stop|status}'
        echo '       stop                       - backup ramdisk data'
        echo '       start|*                    - restore ramdisk data from backup'
        echo '       - default backup location is /xxxxx'
        exit 1
        ;;
esac


exit $?

Pouco aviso para usuários do Ubuntu, não use / media / usuário / para backups de ramdisk, pois ele é redefinido por algumas atualizações, então eu estava perdendo dados de perfil periodicamente. Também com o Ubuntu eu tive algumas dificuldades em criar "ramdisk bakups" em pastas pessoais criptografadas.

Espero que isso ajude alguém.

    

Answer 5

Se você não quiser gastar tempo para despachar seus dados através de HDD e SDD, você pode usar seu SDD como um cache.

• Cache L2ARC no ZFS (Solaris, * BSD)
• Bcache (Linux) É código alfa ainda, então talvez não seja confiável

Answer 6

Sinto muito, más respostas. É claro que você pode e deve construir um sistema muito rápido e ainda mover a maioria das pastas escritas para o HDD. Mover / tmp para / tmpfs ou criar / tmp partição no HDD também mover para o HDD e criar links simbólicos nas pastas originais para / var / log / var / spool e / var / tmp (não coloque / var / tmp no tmpfs como lá são dados que devem estar acessíveis através de reinicializações). Mova para o HDD e crie links simbólicos para ~ / Downloads ~ / Videos ~ / Music ~ / .config ~ / .cache ~ / .thunderbird ~ / .mozilla ~ / .googleearth ~ / .ACEStream e outros que você conhece ou descobre escrever com frequência caches (sempre descubra onde está o seu cache de navegador específico e mova-o para o HDD. O Chrome e o Firefox são cobertos por esses que acredito, mas verifique você mesmo). Se você precisar editar um arquivo de vídeo, poderá movê-lo para ssd. Caso contrário, 99% dos documentos e mídias não serão beneficiados pelo SSD. Além disso, como o HDD é muito menos usado pelo sistema, esses truques têm um impacto negativo no desempenho e uma enorme diferença na durabilidade do SSD. Mova para o HDD e crie links simbólicos para suas pastas na nuvem (por exemplo, dropbox). Considere também mover / var / www se você estiver fazendo isso. Agora você tem um sistema muito rápido, com quase nenhuma diferença de velocidade e com muito menos desgaste.