Cosa NON mettere su un SSD?

Ho acquistato un SSD e ho intenzione di configurare il mio sistema desktop con un'installazione Linux completamente nuova.

Gli SSD sono noti per essere veloci, ma presentano uno svantaggio: il numero di scritture (per blocco?) È limitato.

Quindi sto pensando a quali dati dovrebbero essere posizionati sull'unità SSD e quali sull'unità HDD. In generale, ho pensato che i dati che cambiano frequentemente debbano essere collocati sull'HDD e quelli che non cambiano frequentemente possono essere inseriti sull'SSD.

• Ora ho letto questa domanda, con uno scenario simile. Nelle risposte c'è scritto: "Le unità SSD sono ideali per lo spazio di scambio ..."

  Perché gli SSD sono ideali per lo spazio di swap? OK, vedo un elevato potenziale per aumentare le prestazioni del sistema, ma lo scambio di dati non cambia frequentemente e quindi ci sarebbero molte scritture sull'SSD con conseguente breve durata dell'SSD?

• E la directory / var? Anche i suoi contenuti non cambiano frequentemente? Non sarebbe una buona idea metterlo sull'HDD?

• Esistono altri dati che non devono essere posizionati su un SSD?

Se ti preoccupi dei cicli di scrittura, non arriverai da nessuna parte.

Avrai dati sul tuo SSD che cambiano frequentemente; la tua casa, le tue configurazioni, le cache del tuo browser, forse anche i database (se ne usi qualcuno). Dovrebbero essere tutti su SSD: perché altrimenti dovresti averne uno, se non guadagnare velocità per le cose che fai di frequente?

Il numero di scritture può essere limitato, ma un SSD moderno è molto bravo a livellare l'usura, quindi non dovresti preoccuparti troppo. Il disco è lì per essere scritto; se non lo usi per quello, potresti anche usarlo come un fermacarte e non metterlo nemmeno sul tuo computer.

Non esiste un dispositivo di archiviazione adatto allo spazio di scambio. Lo scambio è lento , anche su SSD. Se devi scambiare tutto il tempo, è meglio ottenere più RAM in un modo o nell'altro.

Potrebbe essere diverso per lo spazio di swap non utilizzato per lo scambio, ma per scenari di sospensione su disco. Naturalmente più veloce è il supporto di archiviazione utilizzato per questo, più velocemente si sospenderà e si risveglierà.

Personalmente, ho messo tutto su SSD tranne i grandi dati statici. Un film, ad esempio, non deve sprecare spazio costoso su SSD, poiché un HDD è più che abbastanza veloce da riprodurlo. Non funzionerà più velocemente usando l'archiviazione SSD per questo.

Come tutti i supporti di archiviazione, a un certo punto SSD non funzionerà, sia che lo si usi o meno. Dovresti considerarli affidabili quanto gli HDD, il che non è affatto affidabile, quindi dovresti fare dei backup.

Ok, quindi l'obiettivo è quello di ottenere il massimo profitto possibile: velocità rispetto al prezzo dell'hardware di sostituzione (supponendo un singolo disco rigido di grandi dimensioni e un SSD di medie dimensioni, che sembra essere la norma). Per semplificare, puoi valutare quanto noti l'aumento della velocità dallo spostamento di un file sull'unità SSD rispetto al numero di settori scritti per spostare tale file sull'unità SSD.

• I file che devono essere letti molto e scritti raramente (come il sistema operativo e i programmi) sarebbero probabilmente i più ovvi da spostare sull'SSD.
• I file che vengono scritti una volta e letti più volte a una velocità dati fissa in cui l'HDD è abbastanza veloce (ad esempio musica, video) dovrebbero probabilmente rimanere lì. Di solito non vengono modificati, ma si considera che sono scritti in molti settori.
• I file piccoli che vengono modificati molto (come alcuni file temporanei) sono più complicati. Ad esempio, data una dimensione del settore di 512 byte, è possibile sovrascrivere un file a settore singolo 20.000.000 di volte prima di "consumare" la stessa quantità di scritture della scrittura di un singolo file da 1 GiB una volta. Se l'SSD si occupa del livellamento dell'usura, questi dovrebbero essere equivalenti.

Naturalmente, anche i migliori calcoli utilizzano anche la risorsa più preziosa di tutte, il tempo. Quindi, nel lungo periodo, probabilmente è meglio mantenerlo semplice e acquistare nuovo hardware leggermente più spesso del case assolutamente ideale.

Accanto a tutte le risposte qui c'è un piccolo suggerimento che mi piace. Ho ricominciato a usare ramdisk con il mio SSD per rallentare un po 'l'effetto dell'usura. Lo sto usando per una cache del browser (ben intero profilo del browser), varie temperature, alcuni registri non essenziali ecc. (Tramite link simbolici)

Il mio ramdisk è impostato in fstab come segue:

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

Più RAM hai ramdisk più grandi che puoi usare in modo efficiente. Con questo ho script di avvio / arresto. Varie esperienze con la scrittura di backup ramdisk su dispositivi / cartelle crittografati anche con la priorità più bassa all'avvio e massima all'arresto.

Ciò accelera leggermente il sistema e consente di risparmiare alcuni cicli di scrittura. La cosa buona potrebbe essere un cron job che fa rsync ogni 15 minuti?

#!/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 $?

Piccolo avvertimento per gli utenti Ubuntu, non usare la cartella / media / user / per i backup di ramdisk in quanto viene ripristinato da alcuni aggiornamenti, quindi perdevo periodicamente i dati del profilo. Anche con Ubuntu ho avuto qualche difficoltà a preparare i ramup disk su una cartella home crittografata.

D'accordo con gli altri, dovresti mettere praticamente tutto tranne che potrebbero essere file (video) molto grandi per evitare di sprecare spazio SSD costoso.

Tuttavia, dovresti anche assicurarti che TRIM sia abilitato:

• Il tuo SSD supporta TRIM
• La partizione è allineata su un multiplo di EBS
• Il tuo file system supporta TRIM sul tuo file system (di solito ext4 lo fa)
• Si esegue fstrimregolarmente (probabilmente in un settimanale cron)
• Hai almeno il 25% di spazio libero su disco [ 1 ]

Ricorda di eseguire il backup dei dati.

AGGIORNARE:

• Arch consiglia di non inserire lo swap su SSD per evitare l'usura

Se non vuoi perdere tempo a inviare i tuoi dati su HDD e SDD, puoi utilizzare il tuo SDD come cache.

• Cache L2ARC su ZFS (Solaris, * BSD)
• Bcache (Linux) È ancora un codice alfa, quindi forse non affidabile

Mi dispiace, cattive risposte. Certo che puoi e dovresti costruire un sistema molto veloce e spostare ancora la maggior parte delle cartelle scritte su HDD. Spostare / tmp in / tmpfs o creare / tmp su HDD anche spostarsi su HDD e creare collegamenti simbolici su cartelle originali per / var / log / var / spool e / var / tmp (non inserire / var / tmp su tmpfs come sono i dati che dovrebbero essere accessibili attraverso i riavvii). Passa a HDD e crea collegamenti simbolici per ~ / Download ~ / Video ~ / Musica ~ / .config ~ / .cache ~ / .thunderbird ~ / .mozilla ~ / .googleearth ~ / .ACEStream e altri che conosci o scopri che scrivi frequentemente cache (trova sempre dove si trova la tua specifica cache del browser e spostala su HDD Chrome e Firefox sono coperti da quelli che credo, ma controlla tu stesso). Se è necessario modificare un file video, è possibile spostarlo su SSD, altrimenti il ​​99% dei documenti e dei media non ha alcun vantaggio nell'essere su SSD. Inoltre, poiché l'HDD è molto meno utilizzato da Systen, questi trucchi hanno un impatto negativo sulle prestazioni e un'enorme differenza nella durabilità dell'SSD. Passa a HDD e crea collegamenti simbolici per le tue cartelle cloud (es. Dropbox). Considera anche di spostare / var / www se lo stai avvicinando. Ora hai un sistema molto veloce con quasi nessuna differenza di velocità e con molta meno usura.