Recomendaciones para el uso de un SSD en GNU/Linux

Hace poco instalé Debian en mi SSD y he estado configurando para dejar el sistema lo más estable y configurado que pueda. Para así, poder hacer una copia de seguridad con Clonezilla.

Los discos de estado sólido son increíblemente rápidos y están carentes de cualquier pieza mecánica móvil, lo que los hace silenciosos, soportan mucho mejor las vibraciones y los golpes y no se ven afectados (o casi) por problemas tales como la fragmentación del sistema de ficheros. Aunque evidentemente, hay que tener en cuenta una serie de consideraciones para sacarles el máximo partido y prolongar su vida útil tanto como sea posible.

Tamaños de las particiones

Las particiones deben ser de tamaño múltiplos exactos de 512MB. Además es muy recomendable crear una partición en un disco duro de toda la vida para almacenar los datos del /home. Así pues tener dos particiones como minimo, donde en una guardaremos el boot y el resto será /.

Pondremos /home en un disco duro de toda la vida porque unos de los inconvenientes que traen los discos duros sólidos es que pierden velocidad de escritura según se va llenando el disco. Este problema va mejorando con la salida de nuevos controladores que gestionan mejor el vaciado de datos, pero de momento sigue estando ahí. Esto es lo recomendado, si lo que quieres realmente es acceder a tus datos rápidamente haz lo que tengas que hacer.

Formatos de las particiones

Los formatos más recomendables son los siguientes:

  • ext4 (recomendado)
  • btrfs
  • f2fs
  • xfs
  • jfs

Todos estos formatos soportan TRIM. ¿Qué significa que soporte TRIM? Pues que permite que el sistema operativo informe a una unidad SSD sobre qué bloques de datos no están en uso y pueden ser borrados. Esto tiene especial importancia en el caso de los discos de estado sólido, pues las memorias flash de tipo NAND que componen los SSD no pueden sobrescribir datos existentes. Antes de escribir nuevos datos sobre los existentes, es necesario borrarlos primero. A este problema se suma el hecho de que la unidad mínima de borrado es un bloque, mientras que la unidad de escritura mínima es una página (un bloque son 64 páginas).

DtC2sBhEsto significa que conforme pasa el tiempo, el disco SSD se irá, en cierto modo, fragmentando internamente (no de la misma manera que los discos duros tradicionales) quedando páginas con bloques vacíos, lo que hará que en algún momento que aún cuando haya espacio libre en el SSD, no quedarán páginas vacías en las que escribir. Esto hará que disminuya el rendimiento debido a que para escribir datos nuevos habrá que reagrupar los bloques que están dispersos, copiándolos a una memoria intermedia, borrándolos y reuniéndolos todos de nuevo en una misma página.

Cuando se borra un archivo, lo que hace el sistema operativo es marcarlo como borrado dentro del sistema de archivos, pero no se lo comunica al disco de estado sólido. Es por eso que TRIM, que como ya hemos dicho se encarga de informar al disco de estado sólido qué está borrado, nos ayuda a evitar los problemas antes mencionados.

Configuración de TRIM

Primero comprobaremos si nuestros SSD tiene soporte para TRIM con el siguiente comando:

Donde X es la letra de tu SSD. La respuesta del comando será clara, si te muestra algo parecido como la siguiente imagen tienes soporte para TRIM, si no aparece nada no lo tienes.

TRIM2

Se puede configurar TRIM de tres maneras: manualmente, configurando el fstab y programando la ejecución de fstrim por cron o systemd.

Manualmente

Instalaremos el paquete fstrim:

Ejecutamos el siguiente comando para activar TRIM:

En el Punto de Montaje deberemos indicar donde está montado nuestro SSD. Lo normal es que sea en / (Raíz o root).

Configurando /etc/fstab

Con la opción discard en el fichero fstab podemos configurar nuestro SSD para que use TRIM. Basta con añadir la opción como se muestra en el ejemplo de abajo:

Programando la ejecución de fstrim

El método más afectivo es la ejecución programada de fstrim que nos permite disfrutar de los beneficios de éste sin apenas efectos en lo que a rendimiento se refiere.

Mediante cron

¿Una tarea programada? Solo me viene a la cabeza una cosa: cron. Crearemos el siguiente fichero /etc/cron.daily/trim para que la ejecución de fstrim se realice diariamente y escribiremos en él:

Damos permisos de ejecución:

Mediante systemd

Si tu GNU/Linux usa systemd quizás te interesará hacerlo de la siguiente manera. Primero creamos un archivo en /lib/systemd/fstrim.service cuyo contenido será el siguiente:

Nota: Donde / será el punto de montaje de la raíz.

Habilitamos el servicio con systemctl

Montaje de particiones

Otra cosa que tendremos en cuenta es el montaje de las particiones donde guardamos el sistema y el arranque. En el fichero de configuración /etc/fstab añadiremosla opción noatime para mejorar las prestaciones del disco.

El uso de las opciones noatime, nodiratime o relatime pueden mejorar las prestaciones del disco. De forma predeterminada, GNU/Linux mantiene un registro (lo escribe en el disco) de cada lectura efectuada atime. Esto es útil cuando se usa GNU/Linux para servidores, pero no tiene mucho valor cuando se usa para escritorio. El inconveniente de la opción predefinida atime es que incluso la lectura de un archivo desde la memoria caché (lectura desde la memoria, en lugar desde el disco directamente), aún en este caso, ¡resultará registrado! Usando la opción noatime deshabilita completamente la actualización del tiempo de acceso a los archivos cada vez que se lee un archivo. No añadiremos las dos opciones noatime y nodiratime, ya que noatime ya incluye nodiratime.

Directorios temporales

También montaremos los directorios temporales (/tmp, /var/run, /var/lock y /var/log) en la RAM para evitar escrituras en disco. Si tienes poca RAM, hasta es mejor tener una particion en un disco duro de toda la vida. Las montaremos con las opciones noatime,nodiratime,nodev y nosuid.

Configurar GRUB: Planificador de entrada/salida

En general, la gran mayoria de GNU/Linux usan CFQ para planificar la entrada/salida de los dispositivos. Sin embargo, para discos SSD existen otras opciones que resultan ventajosas:

  • noop (recomendado)
  • deadline

Si el SSD será el único medio de almacenamiento del equipo, configuraremos el GRUB para lo ajuste mediante la opción elevator que añadiremos en el fichero /etc/default/grub.

Buscaremos en el fichero algo como “GRUB_CMDLINE_LINUX=”” y lo dejaremos así:

Guardamos los cambios y actualizamos el grub con este comando:

¿SWAP o no SWAP?

He leído en muchos artículos que el uso de la SWAP no se tiene que hacer en un disco duro por el tema de que estaríamos reduciendo su vida útil, aún así podemos configurar una SWAP (en el caso de que tengamos muy poca RAM) pero con unos matices:

  • Reducir el porcentaje de uso SWAP/RAMM al 1%
  • Disminuir valor de cache de bloques de datos de 100 a 50
  • Modificar la frecuencia de acceso al disco de 500 a 1500

Para ello modificaremos el siguiente fichero /etc/sysctl.conf y modificaremos o añadiremos estos valores:

Reducir el número de chequeos en los sistemas de ficheros

Como sabemos, cada cierto número de veces que iniciamos el sistema se realiza de forma automática un chequeo de los sistemas de ficheros para asegurar que todo sigue como es debido.

Como lo que buscamos es limitar el uso del disco SSD, sería una buena idea hacer que estos chequeos ocurran menos a menudo modificando el intervalo de tiempo o el número de reinicios que transcurren entre uno y otro.

Mediante tune2fs podemos modificar este valor y también hacer otras muchas cosas, apuntando siempre a la partición sobre la que queremos actuar:

Test de velocidad

Como curiosidad, con el comando hdparm -Tt /dev/sdX podemos hacer un test de velocidad de escritura, para que veáis una diferencia he realizado dos tests; uno en un SSD y otro en un disco duro de toda la vida. Este es el resultado:

 

Fuentes: Ubuntu-es, NoRender, WikiArchLinux, WikiDebian.

El contenido de esta entrada está bajo licencia Creative Commons

Zagur

Técnico Superior de Administración de Sistemas. Estudiando actualmente Desarrollo de aplicaciones web. #GNU #Linux #CSS #HTML #Python #SoftwareLibre #OpenSource

20 comentarios “Recomendaciones para el uso de un SSD en GNU/Linux”

  1. karlinux free

    Navega con Unknown Unknown en Unknown Unknown

    Otro aspecto interesante sería desviar la descarga del software que tenemos que instalar a una carpeta en otro disco duro mecánico si tenemos dos discos duros. En el caso concreto de sistemas basados en debian habría que crear por ejemplo una carpeta en el /home/usuario que tengamos (p.e. la carpeta “software”) y a traves de la creación del archivo /etc/apt/apt.conf y metemos ahí la linea con la ruta de los paquetes. introducimos la siguiente línea para el ejemplo:

    dir::cache::archives “/home/usuario/software”;

    (La ruta habría que modificarla según el usuario y la carpeta creada)

    Así nos ahorramos escribir si cabe más en el disco duro.

        • karlinux free

          Navega con Unknown Unknown en Unknown Unknown

          Lo interesante es que la carpeta home esté en el disco duro mecánico porque es una carpeta que va a estar escribiendo casi a todas horas… Imaginemos Disco Ssd que es el prinicpal estará en /dev/sda y el mecánico estará en /dev/sdb. Bien pues si la carpta /home que es donde van las carpetas de usuarios está en /dev/sdb valdría el hack, pues lo que hacemos es crear una carpeta dentro de tu carpeta home… Supongamos que tu usuario es “slnk”, pues dentro de tu home puedes crear una carpeta que se llame por ejemplo “paquetes”. La ruta de esa carpeta sería /home/slnk/paquetes. lo siguiente sería crear un archivo que contenga la línea anterior. Para ello te metes en el terminal y tecleas (esto solo vale para debian y distribuiciones “deb”):

          sudo nano /etc/apt/apt.conf

          Ahora en la propia terminal lo correcto sería poner lo siguienet dado tu usuario y la carpeta que acabas de crear:

          dir::cache::archives “/home/slnk/paquetes”;

          Pulsas crtl+o y guardas el documento

          Ahora cada vez que instales paquetes o actualices el sistema los paquetes que deb que descarga se guardarán en esa carpeta, con lo que minimizas el uso del disco ssd, le das más vida

          En distribuiciones basadas en archlinux abría que modificar el el archivo /etc/pacman.conf y decomentar la linea de caché de los archivos, poniendo esa misma ruta

          Otra cosa que evitaría hacer esto mismo pero que es un resultado similar es crear en la instalacion del sistema operativo la particion /var en el disco duro mecánico, partición donde “todas” las distribuciones linux guardan lso datos referentes a los paquetes de software. La partición debería de ser de 8 a 15 gb, y el formato al tratarse de un disco duro mecánico hdd, la que más rabia te dé ext4. brtfs….

    • slnk

      Navega con Unknown Unknown en Unknown Unknown

      Hola karlinux free,
      puedes si no es mucho lio explicarme con mas detalle como puedo hacer esos paso?

      Gracias

  2. taregon

    Navega con Unknown Unknown en Unknown Unknown

    Un pequeñísimo error, tienes escrito al final hdpram -Tt /dev/sdX y la foma correcta es hdparm. Me gusto el comando, nunca lo vi antes. Otra cosa, tuve que ejecutarlo con “sudo”. Por cierto, muy buen post 🙂

  3. slnk

    Navega con Unknown Unknown en Unknown Unknown

    Hola,
    me viene genial este artículo, es muy bueno. Aprovecho para presentar una duda.
    Ayer mismo compre una torre con:
    1. Disco SSD SAMSUNG 2.5 120GB SATA3 SERIE 840EVO (preinstalado W7?
    2. Disco SEAGATE 1TB 7200 SATA III 64MB (datos)

    Soy usuario de Kubuntu desse hace 3 años, actualmente soy Autónomo y voy a manejar para mi
    empresa cantidad de bases de datos y programas de gestion empresarial.
    Me gustaría hacerlo con Linux y he leido que Ubuntu 12.04LTS es de las mejores opciones.

    ¿Como me aconsejais que lo instale en la SSD?
    ¿los programas de cada S.O es recomendable particionar el SATA III e instalarlos ahí, dejando el SSD sólo para los SO?
    ¿como creeis que es la mejor forma de hacerlo?

    Muchas gracias

    • Zagur

      Navega con Unknown Unknown en Unknown Unknown

      Es importante que las particiones que vayas a poner en el SSD sean particiones donde se escriban poco, ya que el principal inconveniente en un SSD es que pierde velocidad a medida que se va llenando y escribiendo en el mismo sitio. Por lo tanto, lugares como /home o /var que constantemente se está escribiendo es mejor dejarlas en particiones del disco mecánico.

      Te aconsejaría que en el SSD dejaras la partición de arranque /boot y la del sistema operativo / para que así fuera rapido. Si usas BD seguramente las guardarás en /var/www, no? De ser así es mejor meter una partición en el disco mecanico con eso.

      Yo personalmente tengo Windows todo en el disco mecánico porque uso más GNU/Linux que Windows..xD

      Por otra parte, instalar Ubuntu 12.04 es mala idea, porque creo que han dejado de dar soporte a esa LTS ya que ahora ha salido una nueva, la 14.04 LTS. Entonces recomiendo esa porque así tendrás 5 años de soporte (y pensando que es para una empresa va genial).

  4. Sergio Sam

    Navega con Unknown Unknown en Unknown Unknown

    mi no entender si uno se compra un sdd para realmente hacer uso de la gran velocidad del disco … y depues montas temp y algunos montan la swap en un disco tradicional asi no estarias desperdiciando la velocidad del sdd que te compraste ???

    • Zagur

      Navega con Unknown Unknown en Unknown Unknown

      El tener una SWAP es opcional. No es necesario. La cuestión es que si pones una SWAP en un SSD es una tontería y estás quitandole vida inutilmente. Por eso en el artículo pone que si se quiere SWAP es mejor ponerla en el disco mecánico.

      Montar los directorios temporales en la RAM solo es recomendable si tienes mucha RAM, ya que esos directorios se escriben continuamente y eso para el SSD no es recomendable.

      Saludos Coordiales.

  5. David

    Navega con Google Chrome 39.0.2166.2 Google Chrome 39.0.2166.2 en GNU/Linux x64 GNU/Linux x64

    Hola a todos, llevo un rato leyendo artículos y la verdad es que me ha gustado esta web, va ahora mismo a favoritos…

    Bueno el caso es que soy usuario de ubutu desde hace tiempo y me acabo de comprar un ssd para mi portatil, concretamente un samsung 840 evo de 250 gigas, ahora me estoy rompiendo la cabeza pensando en como “reubicar” las particiones.

    Mi portatil tiene un disco móvil de 1 TB y además un ssd de 8 gigas (samsung lo llamaba express cache o algo así) que tengo como swap aunque no se utiliza casi ya que tengo 8 gigas de ram. En el disco de 1TB tengo muchas particiones, que se reparten entre windows 8, ubuntu y las particiones de recuperación de windows entre otras.

    Mi idea inicial era hacer dos particiones en el ssd, una para el sistema windows (dejando las carpetas temporales, users, y archivos de programa en el disco móvil) y la otra para ubuntu (dejando igualmente /home en el disco móvil), lo de dejar también los temporales y /var en el disco móvil no lo había pensado por eso de no perder velocidad ¿Se notaría esto realmente?. Sin embargo estaba leyendo en todas partes en internet que no es conveniente particionar el disco ssd ¿sabeis si esto es cierto y por que?, otra cosa mas ¿por que decís de poner /boot en otra particion? al fin y al cabo estaría en el mismo ssd ¿no?

    Despues de leer esto no se si mi planteamiento inicial es el adecuado, ¿Debería usar el disco ssd de 8 gigas para /boot y poner la swap en otro sitio? ¿o debería quitar la swap?

    Muchas gracias de antemano
    Un saludo

    • Zagur

      Navega con Firefox 32.0 Firefox 32.0 en GNU/Linux x64 GNU/Linux x64

      Gracias por estar entre tus favoritos! Difundir el blog es lo mejor que puedes hacer para que esto crezca cada día, así que puedes seguirme en Twitter, Facebook o Google +! (y hasta aquí mi comentario de spam xD)
      Vamos a lo importante. La idea principal de combinar SSD y Disco duro mecánico (o móvil, como se acabe de llamar), es hacer que el disco SSD se ocupe de la parte del SO que no va a escribir constantemente en el disco por el principal inconveniente que traen los discos duros sólidos que pierden velocidad de escritura según se va llenando el disco. Por lo tanto, yo recomiendo poner en el SSD arranque de Windows, instalación de Windows, /boot, y /. Y en el disco mecánico poner una partición para Programas y juegos, datos (del usuario), /home, /var (aquí se guardan los logs del sistema y se modifican cada segundo). Partición cache no pondría, si el SSD ya va rápido y tienes 8 GB de RAM..pff innecesario.
      El disco de 8 GB..puff yo lo quitaria, y dejaria SSD (250 GB) y disco duro (1T). Y podrías poner el de 8 Gb en otro ordenador para montar el arranque. Yo lo tengo más o menos particionado como te he dicho (bueno, no tengo windows instalado) y la verdad es que velocidad he notado y mucha. Hice pruebas con el SSD antes de dejar el sistema operativo instalado, y con un procesador i5 y 8 GB de RAM me iniciaba Kubuntu en 4seg aproximadamente. Una burrada… Hice pruebas con el otro disco duro y tardaba 12 segundos en iniciar. Mola esto de tocar el botón del PC sentarse y poner contraseña para loguearte.
      En cuanto a lo de poner /boot en otra partición, es pura “seguridad”. En caso de que el arranque muera por cualquier cosa, solo tengo que formatear esa partición, instalar el arranque de nuevo y ya tengo el problema resuelto. De la misma manera que tengo el /home en otra partición, porque si el sistema se peta por alguna razón, saber que tengo una partición con mis datos y poderlos recuperar sin problemas.
      Espero haberte resuelto las dudas, y si tienes alguna pregunta más no dudes en responder.
      Saludos,
      Zagur.

  6. David

    Navega con Google Chrome 37.0.2062.124 Google Chrome 37.0.2062.124 en Windows 8.1 x64 Edition Windows 8.1 x64 Edition

    Gracias por estar entre tus favoritos!

    Encantado, para eso estan…

    Difundir el blog es lo mejor que puedes hacer para que esto crezca cada día, así que puedes seguirme en Twitter, Facebook o Google +!

    ¡Ya estaba hecho!

    Muchas gracias por responder, esa era mi idea principal, tener el ssd para el sistema operativo (ya sea solo ubuntu o ambos) y el disco mecánico (no se si lo de móvil me lo he inventado mientras escribía…) para almacenar los datos que es lo que se irá modificando. Sin embargo había pensado en instalar también en el disco mecánico los programas de windows o al menos los archivos temporales, ya que esas carpetas en windows se llenan en seguida de “basura” y así me ahoraría tener eso en el ssd.

    Sobre lo del disco de 8 gigas, es imperativo que este ahí, mas que nada porque va integrado en la placa. Este es mi portatil: Samsung np700z5c, y cuando dice “ExpressCache™ Technology, 8GB” se sefiere a un ssd de 8 gigas que esta integrado en la placa y que se usaba para aumentar la velocidad de windows, pero que en ubuntu yo no lo veía necesario, de todas formas podría instalar en el /boot y tenerlo ahí por el tema de seguridad como me comentabas, lo malo es que entonces me da la sensación de que desperdicio 8 gigas solo para /boot…

    Una cosa mas que no se si es posible, ¿se puede tener tanto /var como /home en una misma partición en el disco mecánico? yo lo que suelo hacer es montar la partición de datos en /home, pero no puedo montar una partición en dos sitios distintos… ¿o si?

    Un saludo

  7. mitcoes

    Navega con Google Chrome 39.0.2171.95 Google Chrome 39.0.2171.95 en GNU/Linux x64 GNU/Linux x64

    sudo hdparm -Tt /dev/sda
    [sudo] password for manjaro1214:

    /dev/sda: 2Tb HDD Seagate
    Timing cached reads: 4760 MB in 2.00 seconds = 2380.17 MB/sec
    Timing buffered disk reads: 300 MB in 3.01 seconds = 99.79 MB/sec
    [manjaro1214@manjaro14 ~]$ sudo hdparm -Tt /dev/sdb

    /dev/sdb: 200 Gb HDD viejete
    Timing cached reads: 4634 MB in 2.00 seconds = 2317.12 MB/sec
    Timing buffered disk reads: 166 MB in 3.03 seconds = 54.73 MB/sec
    [manjaro1214@manjaro14 ~]$ sudo hdparm -Tt /dev/sdc

    /dev/sdc: 120Gb SDD Kingston
    Timing cached reads: 4712 MB in 2.00 seconds = 2356.04 MB/sec
    Timing buffered disk reads: 332 MB in 3.01 seconds = 110.43 MB/sec

    Profunda decepción y alegria de lo bien que van los HDDs

    En Manjaro el comando para ejecutar TRIM es

    sudo systemctl enable fstrim.timer

    https://forum.manjaro.org/index.php?topic=16537.0

    • mitcoes

      Navega con Google Chrome 39.0.2171.95 Google Chrome 39.0.2171.95 en GNU/Linux x64 GNU/Linux x64

      Se me olvidaba, puese /home y /var en el HDD, este último por encarecida recomendación en la comunidad de G+ Linux porque se escribe mucho y hace sufrir a las SDDs, me dijeron que en portátiles con SDD y HDD va lo comido por lo servido, pero en sobremesas es altamente recomendable si tienes ambos

  8. Frank

    Navega con Firefox 35.0 Firefox 35.0 en GNU/Linux x64 GNU/Linux x64

    Hola :
    Me pareció un poco lento el disco ssd que has puesto.
    A mi me arroja resultados muchos mas altos y eso que no uso el intel (que da mucho mas), no quizás revisa eso, no sea que no este bien alineado .
    X79-PRO:~ # hdparm -Tt /dev/sdb

    /dev/sdb:
    Timing cached reads: 24218 MB in 2.00 seconds = 12125.93 MB/sec
    Timing buffered disk reads: 1268 MB in 3.00 seconds = 422.35 MB/sec
    mi fstab para ese disco es : UUID=d8c57867-8bad-41db-85cf-219b41eddd22 /home/frank/VBox_ssd btrfs discard realtime ssd 0 0
    Para repetir la prueba de rapidez 3 veces para comprobar que los resultados son mas o menos iguales, ejecutar en consola :
    X79-PRO:~ # for i in 1 2 3 ; do hdparm -tT /dev/sdb ; done

    /dev/sdb:
    Timing cached reads: 23632 MB in 2.00 seconds = 11831.81 MB/sec
    Timing buffered disk reads: 1270 MB in 3.00 seconds = 423.08 MB/sec

    /dev/sdb:
    Timing cached reads: 24106 MB in 2.00 seconds = 12070.48 MB/sec
    Timing buffered disk reads: 1276 MB in 3.00 seconds = 425.01 MB/sec

    /dev/sdb:
    Timing cached reads: 24520 MB in 2.00 seconds = 12278.07 MB/sec
    Timing buffered disk reads: 1266 MB in 3.00 seconds = 421.64 MB/sec
    Hacer las pruebas con otras particiones sb1,sdb2 etc (si alguna está mal alineada, puede perder bastante en velocidad) .

    Swap puede comportarse como una partición; pero también creo que puede configurarse como fichero (uso de memoria compartida y para hibernar o suspender un equipo) .
    Si es para un equipo de escritorio que nunca se va a suspender y tienes mucha memoria (casi diría que no hace falta) .
    System: Host: X79-PRO Kernel: 3.19.0-2.g1133f88-desktop x86_64 (64 bit) Desktop: KDE 4.14.5
    Distro: openSUSE 20150225 (Tumbleweed)
    Machine: Mobo: ASUSTeK model: P9X79 PRO v: Rev 1.xx Bios: American Megatrends v: 4701 date: 05/07/2014
    CPU: Quad core Intel Core i7-3820 (-HT-MCP-) cache: 10240 KB
    clock speeds: max: 5700 MHz 1: 2379 MHz 2: 1672 MHz 3: 2122 MHz 4: 1664 MHz 5: 2703 MHz 6: 2089 MHz
    7: 2575 MHz 8: 2585 MHz
    Graphics: Card: NVIDIA GK107 [GeForce GTX 650]
    Display Server: X.Org 1.17.1 drivers: nouveau (unloaded: fbdev,nv,vesa) Resolution: 1360×768@60.02hz
    GLX Renderer: Gallium 0.4 on NVE7 GLX Version: 3.0 Mesa 10.4.4
    Audio: Card-1 NVIDIA GK107 HDMI Audio Controller driver: snd_hda_intel
    Card-2 Intel C600/X79 series High Definition Audio Controller driver: snd_hda_intel
    Sound: Advanced Linux Sound Architecture v: k3.19.0-2.g1133f88-desktop
    Network: Card: Intel 82579V Gigabit Network Connection driver: e1000e
    IF: eno1 state: up speed: 1000 Mbps duplex: full mac:
    Drives: HDD Total Size: 5120.9GB (42.1% used) ID-1: /dev/sda model: WDC_WD1002FAEX size: 1000.2GB
    ID-2: /dev/sdb model: KINGSTON_SH103S3 size: 120.0GB
    ID-3: /dev/sdc model: MARVELL_Raid_VD size: 4000.6GB
    Partition: ID-1: / size: 41G used: 23G (61%) fs: btrfs dev: /dev/sda3
    ID-2: /tmp size: 41G used: 23G (61%) fs: btrfs dev: /dev/sda3
    ID-3: /home size: 890G used: 732G (83%) fs: btrfs dev: /dev/sda4
    ID-4: swap-1 size: 2.15GB used: 0.00GB (0%) fs: swap dev: /dev/sda2
    Sensors: System Temperatures: cpu: 23.0C mobo: 24.0C gpu: 25.0
    Fan Speeds (in rpm): cpu: 270000 mobo: 270000 fan-1: 795 fan-3: 0 fan-4: 0 fan-5: 0
    Info: Processes: 345 Uptime: 1 day 0:58 Memory: 1463.7/64372.9MB Client: Shell (ksh) inxi: 2.2.18
    Otra buena idea creo que sería reducir la cache del navegador .

    Gracias por el articulo y saludos muy cordiales

    • Zagur

      Navega con Firefox 35.0 Firefox 35.0 en Ubuntu x64 Ubuntu x64

      Tienes razón, creo que lo copié mal, lo he vuelto hacer y me da el siguiente resultado:
      /dev/sda:
      Timing cached reads: 28842 MB in 2.00 seconds = 14435.64 MB/sec
      Timing buffered disk reads: 1232 MB in 3.01 seconds = 409.76 MB/sec
      Ahora mismo lo modifico, gracias por el aviso.
      Saludos.

Trackbacks/Pingbacks

Comentarios cerrados.

Utilizamos cookies propias y de terceros para mejorar nuestros servicios. Si continúa navegando, consideramos que acepta su uso. Doble clic sobre aquí para cerrar.