¿Qué optimización SSD se necesita en la última versión de Ubuntu?

21

He leído de un montón de preguntas acerca de la optimización de SSD ( ¿Cómo puedo optimizar el sistema operativo para los SSD? , Instalación de Ubuntu en un SSD , estoy confundido acerca de la optimización de SSD , etc ...).

La mayoría de esas preguntas parecen anticuadas (más de 3 años) y estoy un poco confundido con todas las instrucciones que toman las respuestas.

Entonces mi pregunta es: a partir de hoy, ¿cuál es el consenso general sobre la optimización de SSD en Ubuntu 14.04 / 15.04?

¿Esto es necesario ahora?

ssd performance

— hg8
fuente

44

Lectura "obligatoria": sites.google.com/site/easylinuxtipsproject/ssd Los consejos siguen siendo válidos. Y lo resume muy bien para cualquier puntero que necesite. Desde la forma en que Ubuntu lo utiliza, hasta la configuración del navegador.

— Rinzwind

17

La cosa es, en primer lugar la mayor parte importante de los SSD se minimiza la escribe en el disco, por lo que la gente añade nodiratime, noatimeal /etc/fstabarchivo.

En segundo lugar, se está ejecutando loTRIM que recupera los bloques no utilizados de memoria NAND de nuevo a SSD. Windows tiene TRIM habilitado por defecto, AFAIK, por lo que nadie se molesta allí. Con Ubuntu, tiene un cronjob semanal para TRIM, sin embargo, por la respuesta de Rinzwind he aprendido que el trabajo cron solo se ejecuta en SSD Intel y Samsung. Es por eso que tiene que editar ese /etc/cron.weekly/fstrimarchivo para que tenga exec fstrim-all --no-model-checklínea, para que se ejecute sin importar cuál sea su modelo de SSD.

En los últimos años, esto no ha cambiado: estos siguen siendo puntos clave, minimizan las escrituras y habilitan TRIM.

Eliminar las escrituras y la cantidad de almacenamiento costosa son los dos factores por los que las personas también eliminan el área de intercambio . Por defecto, Ubuntu crea una partición de intercambio igual al tamaño de su RAM. Tengo un SSD de 128 y 6 GB de RAM. Eso significa que, por defecto, Ubuntu cortará 6 GB de 128 GB, dejando 122 GB para mi sistema operativo, y el 5% generalmente está reservado para root, por lo que me deja 122-122 * 0.05 = 115.9 GB para mí. También podría usar ese almacenamiento para otra cosa, por lo que solo tengo una partición principal, ninguna partición de intercambio, pero tengo un archivo de intercambio de 512 MB como característica de protección (no es que planeo quedarme sin RAM, pero siempre se recomienda tener intercambio)

— Sergiy Kolodyazhnyy
fuente

Acerca de noatime: algunas aplicaciones pueden depender de la comparación de los tiempos de modificación y acceso, pueden funcionar mal, realtimees mejor y, dado que Linux kernel 2.6.30 está activado de manera predeterminada, no es necesario configurarlo. Puede verificar cómo se montaron sus sistemas de archivos ejecutando el comando$ cat /proc/mounts

— Mike

@ Mike acaba de ejecutar el cat /proc/mounts. Para mi disco no se muestra relatimehabilitado, solo noatimey en el nodiratimeque lo habilité explícitamente /etc/fstab. En cuanto a noatime, ¿puede proporcionar algunos ejemplos de qué aplicaciones dependen de él?

— Sergiy Kolodyazhnyy

2

Perdón por el error tipográfico que realtimequise decir relatime.

— Mike

2

noatimeimplica nodiratime, ver man mountsobre noatime:

Do not update inode access times on this filesystem (...). This works for all inode types (directories too), so implies nodiratime.

Además, en mi humilde opinión, no es necesario usar noatimecuando relatimeprobablemente no rompería la funcionalidad y parece una opción decente (también se recomienda en: SSDOptimization en wiki.debian.org ).

— Dor

2

Continúe de mi publicación anterior: ... escribí "decente" porque ¿cuántas veces les sucede a los archivos que su tiempo de acceso es anterior a su tiempo de modificación? Especialmente con respecto a los archivos del núcleo y todos los archivos que están en /. Según man mount: desde Linux 2.6.30, el núcleo por defecto es el comportamiento de relatime. TL; DR Desde Ubuntu 16, evite hacer cualquier cosa :-)

— Dor

6

La única cosa que puede que tenga que hacer es añadir --no-model-checka /etc/cron.weekly/fstrim.

La línea debería verse así

exec fstrim-all --no-model-check

Verifique que su SSD sea compatible con TRIM (casi todos los modelos recientes)

sudo hdparm -I /dev/sda | grep "TRIM supported"

si su SSD es /dev/sda. Si es así, agregue --no-model-check.

— Piloto6
fuente

1

Básicamente, los SSD de más de 2 años pueden ser problemáticos.

— Rinzwind

6

Funciona bien con SSD que admite TRIM

para 16.04 no hay

fstrim-all

fstrim simple no tiene --no-model-check y funciona bien con sandisk ssd

— David Ambarsumov
fuente

0

En general, Ubuntu admite unidades de estado sólido muy bien.
Si tiene una inteligencia o una SSD SAMSUNG, la compatibilidad con el recorte automático está habilitada de forma predeterminada.

No tiene que preocuparse mucho con una excepción:
debe almacenar sus datos personales en un HDD para reducir la cantidad de escrituras en SSD.

— cl-netbox
fuente

rara vez se escriben datos personales

— endolith

2

"Los datos personales rara vez se escribe a" a excepción de la caché del navegador, todos los documentos y hojas de cálculo hace clic en Guardar, todo lo que descargue, cualquier cosa en la copia de carga ...

— kmarsh

¿No es ese exactamente el propósito de un SSD? ¿Para acelerar cosas como el caché del navegador, etc.? Y editar documentos ... Bueno, incluso si edita 20 documentos grandes todos los días, que son de 1 MB cada uno, eso es un máximo. de 20 MB de escrituras al día ... Eso no es mucho. No vale la pena la molestia adicional de agregar un disco duro.

— Andreas