Hola amigos.
Hace un tiempo Alfredo decía que su sistema iba lento, y en aquel momento no se me ocurrió que podría ser lo que lo causase, y pensé que estaría este estaría haciendo algo mal, porque, ¿Como iba Linux a ir lento? Así que no fui muy amable en aquel momento. Lo siento Alfredo.

Pero resulta que se pueden hacer un par de cosas para acelerar el sistema.
Bien, como hoy toco mantenimiento de mi sistema que es un Manjaro, me puse a revisar la lista de rutina y descubrí que no estaba activado ni funcionando el servicio TRIM y como uso un disco SSD eso no es bueno. Así que lo active, luego aplique unos consejos del manual de Arch para acelerar el navegador chromium y también incremento la velocidad del sistema.

Si tienes un SSD

• Consultando si esl sistema soporta TRIM: lsblk --discard
  
• Activar los servicios: fstrim.service y fstrim.timer
  
• Hacer de vez en cuando find ~/.cache/ -type f -atime +100 -delete
  

Luego para Chromium, conviene ejecutarlo con la siguiente orden.
chromium --disable-sync-preferences --disk-cache-dir="$XDG_RUNTIME_DIR/chromium-cache" --user-data-dir=/tmp/chromium

Hola Tincho,

a lo que tu indicas (que ya lo tenía hecho) puedes «optimizar» el arranque del disco desde el fstab, esta es la configuración que utilizo para mi ssd (los detalles se explican en el manual de fstab)

UUID=<mi uuid> /              ext4    noatime,nodiratime,discard,nodelalloc,barrier=0,i_version,commit=30,inode_readahead_blks=64,errors=remount-ro 0 1

Saludos

UUID=<mi uuid> /              ext4    noatime,nodiratime,discard,nodelalloc,barrier=0,i_version,commit=30,inode_readahead_blks=64,errors=remount-ro 0 1

Un poco de información acerca de que hace cada parámetro.

• noatime desactiva por completo la escritura de los tiempos de acceso a los archivos en la unidad cada vez que se lee un archivo. Esto funciona bien para casi todas las aplicaciones, excepto para aquellas que necesitan saber si un archivo ha sido leído desde la última vez que fue modificado. La información del tiempo de escritura a un archivo continuará actualizándose cada vez que se escriba en el archivo con esta opción activada.
  
• discard Emite las órdenes TRIM para dispositivos de bloques subyacentes cuando se liberan los bloques.
  
• nodiratime desactiva la escritura de los tiempos de acceso a los archivos sólo para los directorios, mientras que otros archivos siguen recibiendo los tiempos de acceso.
  
• lazytime  reduce las escrituras en disco manteniendo los cambios en las marcas de tiempo del inodo (tiempos de acceso, modificación y creación) sólo en memoria. Las marcas de tiempo en el disco se actualizan sólo cuando (1) el nodo del archivo necesita ser actualizado por algún cambio no relacionado con las marcas de tiempo del archivo, (2) se produce una sincronización con el disco, (3) un nodo no eliminado es desalojado de la memoria o (4) si han pasado más de 24 horas desde la última vez que la copia en memoria fue escrita en el disco.
  
• nodelalloc  desactiva la función de ext4 de delayed allocation, que reserva el espacio pero no lo escribe. Aplaza la escritura de bloques hasta que se esté en el tiempo de escritura. Es más que nada por seguridad.
  
• barrier=0: Desactiva las barreras automáticamente. Se refiere a los límites de escritura. Si es igual a cero los elimina, si es igual a 1, los activa. Podemos prescindir de estas barreras si los discos están protegidos contra cortes de corriente. Sólo en este caso, incluimos la opción barrier=0
  
• i_version Habilita el uso de la versión extendida de 64 bits en sistemas de ficheros ext4.
  
• commit=30: Retrasa la escritura de los metadatos de ficheros, con lo que se reduce mucho el uso de disco. No recomendable si estuviésemos en un ordenador con batería.
  
• inode_readahead_blks=64 Este parámetro de ajuste controla el número máximo de bloques de la tabla de inodos que el algoritmo readahead de la tabla de inodos de ext4 preleerá en la caché del buffer. El valor por defecto es de 32 bloques.
  

Siguiendo tu ejemplo y cambiando un poco en base a lo que indican en la pagina de Arch, como por ejemplo que noatime implica nodiratime y no es necesario especificar ambos. Luego, agregando dos lineas más a fstab para montar los directorios temporales en la RAM quedo así:

• Escenario 1: Laptop 64 bits con, al menos, 8GB de RAM, batería en buen estado y cargada es decir si se corta la energía el sistema no se apaga abruptamente sino que nos da tiempo a apagar el sistema de forma ordenada. Configurado para hacer TRIM periódico de una vez por semana.
  

UUID=<uuid>   /              ext4    noatime,nodelalloc,barrier=0,i_version,inode_readahead_blks=64,errors=remount-ro 0 1

• Escenario 2: Igual que escenario 1 pero con TRIM continuo.
  

UUID=<uuid>   /              ext4    noatime,discard,nodelalloc,barrier=0,i_version,inode_readahead_blks=64,errors=remount-ro 0 1

 

tmpfs   /tmp   tmpfs         size=2G,noexec,rw,auto,nouser,sync,noatime,nodev,nosuid,mode=1777 0 0
tmpfs   /var/tmp   tmpfs   size=2G,noexec,rw,auto,nouser,sync,noatime,nodev,nosuid,mode=1777 0 0

Aquí debajo transcribo las notas de la pagina de Arch linux sobre el tema:

TRIM continuo
Nota: No hay necesidad de habilitar TRIM continuo si ejecuta fstrim periódicamente. Si quiere usar TRIM, use TRIM periódico o TRIM continuo.
En vez de ejecutar los comandos TRIM cada tanto (por defecto es una vez por semana si usa fstrim.timer), también es posible emitirlos cada vez que un archivo es borrado. Eso ultimo se conoce como TRIM continuo.

Advertencia: Antes de SATA 3.1, los comandos TRIM no eran ejecutados en cola, lo que provocaba que el sistema se congelara frecuentemente. En este caso, aplicar #TRIM periódico menos frecuentemente era una mejor alternativa. Se producía el mismo problema en un numero de dispositivos, vea ata_device_blacklist en el código fuente de Linux, donde la ejecución en cola de comandos TRIM esta prohibida por causar corrupción seria de datos. En ese caso, dependiendo de el dispositivo, el sistema puede estar forzado a enviar comandos TRIM fuera de cola en vez de en cola. Vea Wikipedia:Trim_(computing)#Disadvantages (en inglés) para más detalles.
Nota: El TRIM continuo no es la manera preferida para emitir comandos TRIM en la comunidad de Linux. Por ejemplo, en Ubuntu el TRIM periódico esta activado por defecto [5], Debian no recomienda usar TRIM continuo [6] y Red Hat recomienda usar TRIM periódico en vez de TRIM continuo si es posible. [7]
Usando la opción de montado discard en /etc/fstab habilita TRIM continuo al operar el dispositivo:

¿y discard?

Gracias por la aclaración, no sé en tu máquina, pero en la mía el runtime de gambas no corre si llevo a ram los temporales de \var.

Sls

Gracias por la aclaración, no sé en tu máquina, pero en la mía el runtime de gambas no corre si llevo a ram los temporales de \var.

De nada.
En mi maquina que tiene /var/tmp y /tmp montados en la RAM no sucede eso. Funciona todo normalmente.

---

¿y discard?

Si pones la opción discard TRIM se hara de modo continuo, es decir cada vez que se borre un archivo.
En el caso que plantee antes, que uso en mi pc, no debería tener este parámetro porque en mi sistema tengo configurado el TRIM periódico.
Voy a corregir el ejemplo para aclarar esto.

Comento algo mas que puede ser útil.
En el caso que tengas estipulado fstrim.timer una vez por semana, como es mi caso; generalmente va bien pero a veces luego de una gran actualización de paquetes puede que sea necesario ejecutar manualmente trim si todavía faltan unos días para que este se realice de forma automática con cron.

Para saber cuando se ejecuto la ultima vez y cuando falta para la próxima:

• systemctl list-timers
  

Para ejecutarlo manualmente:

• fstrim --fstab
  

Buenas!.

Lo sé, ya tiene un tiempo el post, pero como son cosas que se van dejando para adelante por motivos de no poder leer completamente el post.

Tincho:

Código:

lsblk --discard

Es un poco larga la salida. Y no tan directa como esta.
Si quieres saber si tu disco soporta trim puedes hacer:

Por ejemplo de todos los parámetros del disco que nos devuelve la instrucción, buscamos la palabra trim.

Código:

# Sustituir la X por la unidad que quieres comprobar a,b...
sudo hdparm -I /dev/sdX | grep -i TRIM

Si queremos saber si tenemos el servicio fstrim en el sistema podemos hacer:

Código:

systemctl cat fstrim.service

Para conocer su estado:

Código:

systemctl status fstrim.timer

Para conocer la configuración del servicio.

Código:

systemctl cat fstrim.timer

Suele ejecutarse cada semana y la salida no te la muestra.
En el caso de que no lo tengamos el servicio, lo podemos activar.

Código:

sudo systemctl enable fstrim.service

Ahora si tenemos el servicio, pero no iniciado. Lo iniciamos.

Código:

sudo systemctl start fstrim.service

Para ver los registros que han ido creando los servicios:

Código:

# Para ver los logs del servicio fstrim.service

journalctl -u fstrim.service

Y ahora el del fstrim.timer.

Código:

journalctl -u fstrim.timer

Saludos

¿ Es normal que un disco externo no ssd tenga capacidad Trim ?. Pues es el tengo dice que tiene esa posibilidad. Es de 6 TB y es magnético.
Creía que eso solo lo tenían los ssd y claro, los hay híbridos.