Esto es lo que obtengo ahora, con un SSD Crucial MX300 de 750 GB (con el último firmware [todavía no hay actualizaciones de firmware]).
lptp [ blah ]: sudo hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 10202 MB in 2.00 seconds = 5103.20 MB/sec
Timing buffered disk reads: 128 MB in 3.06 seconds = 41.88 MB/sec
¡Mira esa velocidad de lectura del disco almacenado! SOOOO SLOWWW !!!! Cuando configuré mi computadora portátil por primera vez, estaba viendo más de 400 MB / seg, lo que estaba perfectamente bien teniendo en cuenta que se trata de una computadora portátil más antigua, y todo está cifrado con suerte.
Este es mi /etc/fstab. He habilitado el recorte, he ejecutado manualmente el recorte, habilitado / deshabilitado las características, reiniciado, todo. No puedo hacer que vuelvan esas velocidades rápidas:
/dev/mapper/ubuntu--gnome--vg-root / ext4 noatime,nodiratime,errors=remount-ro,barrier=0,discard 0 1
Solo para que quede claro, estas son las opciones que estoy usando. He intentado varias combinaciones de ellos en vano:
noatime,nodiratime,errors=remount-ro,barrier=0,discard
¿Algun consejo? Esto me está volviendo loco.
Ah, también, estoy ejecutando Ubuntu 16.04 (x64) en un Lenovo T420 con 16 GB de RAM y un procesador i7:
lptp [ blah ]: lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
Salida de Smartctl:
lptp [ blah ]: sudo smartctl /dev/sda -a
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-38-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Device Model: Crucial_CT750MX300SSD1
Serial Number: XXXXXX
LU WWN Device Id: 5 XXXXX XXXXXXX
Firmware Version: M0CR011
User Capacity: 750,156,374,016 bytes [750 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-3 T13/2161-D revision 5
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Tue Nov 1 21:22:05 2016 CDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 1987) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 10) minutes.
Conveyance self-test routine
recommended polling time: ( 3) minutes.
SCT capabilities: (0x0035) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 100 100 000 Pre-fail Always - 0
5 Reallocated_Sector_Ct 0x0032 100 100 010 Old_age Always - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 52
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 41
171 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0
172 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0
173 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 1
174 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 11
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0
184 End-to-End_Error 0x0032 100 100 000 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
194 Temperature_Celsius 0x0022 059 052 000 Old_age Always - 41 (Min/Max 21/48)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 100 100 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 100 100 000 Old_age Always - 0
202 Unknown_SSD_Attribute 0x0030 100 100 001 Old_age Offline - 0
206 Unknown_SSD_Attribute 0x000e 100 100 000 Old_age Always - 0
246 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 138859820
247 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 4354463
248 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 1675456
180 Unused_Rsvd_Blk_Cnt_Tot 0x0033 000 000 000 Pre-fail Always - 3558
210 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Lo que me está matando es que estaba trabajando por un tiempo . Funcionó un día, y luego se detuvo al siguiente, y ni siquiera hice nada (que se me ocurra) que debería haberlo cambiado.
ACTUALIZAR
Probó un dispositivo específico ( /dev/sda1), pero los mismos resultados lentos:
lptp [ ~ ]: sudo hdparm -Tt /dev/sda1
/dev/sda1:
Timing cached reads: 13130 MB in 2.00 seconds = 6568.77 MB/sec
Timing buffered disk reads: 128 MB in 3.06 seconds = 41.79 MB/sec
ACTUALIZAR
Probado en una partición lógica también:
lptp [ ~ ]: sudo hdparm -Tt /dev/mapper/ubuntu--gnome--vg-root
/dev/mapper/ubuntu--gnome--vg-root:
Timing cached reads: 11468 MB in 2.00 seconds = 5736.85 MB/sec
Timing buffered disk reads: 178 MB in 3.04 seconds = 58.47 MB/sec
ddPrueba de ACTUALIZACIÓN
Esta prueba muestra que es aún más lenta que la de hdparm ...
lptp [ blah ]: dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc status=progress
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 35.0156 s, 30.7 MB/s
lptp [ blah ]: sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"
lptp [ blah ]: dd if=tempfile of=/dev/null bs=1M count=1024 status=progress
1066401792 bytes (1.1 GB, 1017 MiB) copied, 34.0193 s, 31.3 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 34.256 s, 31.3 MB/s
ACTUALIZACIÓN: Alineación de partición
Aquí está la alineación de la partición en mi computadora portátil:
lptp [ ~ ]: sudo parted
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: ATA Crucial_CT750MX3 (scsi)
Disk /dev/sda: 750GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 512MB 511MB primary ext2 boot
2 513MB 750GB 750GB extended
5 513MB 750GB 750GB logical
(parted) align-check opt 1
1 aligned
(parted) align-check opt 2
2 not aligned
(parted) align-check opt 5
5 aligned
(parted)
No estoy seguro de qué pensar si la partición 2 no está alineada: ^ / pero las particiones 1 y 5 sí lo están.
Además, aquí están las particiones como se ve desde fdisk -l
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 999423 997376 487M 83 Linux
/dev/sda2 1001470 1465147391 1464145922 698.2G 5 Extended
/dev/sda5 1001472 1465147391 1464145920 698.2G 83 Linux
ACTUALIZACIÓN: FIJA?
Cambié el planificador a un planificador noop (en lugar de la fecha límite). Eso parece haber funcionado (hizo esto cambiando /etc/default/grubpara tener la línea:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=noop"
Y luego actualizar grub con sudo update-grub2y reiniciar.
Esperaré unos días para ver si funciona después de algunos reinicios / uso más antes de responder y aceptarlo.
Velocidades actuales ahora después de cambiar el planificador:
lptp [ ~ ]: sudo hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 12388 MB in 2.00 seconds = 6197.19 MB/sec
Timing buffered disk reads: 1454 MB in 3.00 seconds = 484.59 MB/sec
Las opciones en fstab son:
noatime,nodiratime,errors=remount-ro,barrier=0
ACTUALIZACIÓN "FIX"
Después de usarlo por un momento y reiniciar varias veces, es VOLVER A LAS VELOCIDADES LENTAS :( :( :( :( :( :(
ACTUALIZACIÓN - POSIBLE "ARREGLO"
Pensé que quizás mi computadora portátil está haciendo algunas optimizaciones de ahorro de batería cuando se arranca y se queda sin batería. Después de una simple prueba de arranque con el cargador enchufado, vuelve a sus velocidades realmente rápidas. Estoy bastante seguro de que este es el caso: todo el tiempo que probó a altas velocidades tenía el cargador enchufado. Haré algunas pruebas más para verificar, pero estoy bastante seguro de que esto es lo que estaba causando la desaceleración.
/dev/sda1lugar de/dev/sda?/dev/mapper/ubuntu--gnome--vg-root/dev/sda1, tambiénRespuestas:
La respuesta rápida:
La respuesta larga:
Parece que Linux o las computadoras portátiles en general (verificadas tanto en Lenovo como en Dell) tienen el nivel APM 80h (128) cuando se inicia con batería y FEh (254) cuando se inicia con alimentación de CA.
Para la mayoría de los SSD, no notará mucha diferencia. Los SSD Lite-on parecen no admitir la administración de energía en absoluto y siempre se ejecutan a la velocidad máxima. Los SSD Intel parecen funcionar a aproximadamente el 75% de la velocidad máxima en el nivel 128 de APM, y el 100% de la velocidad en el nivel 254/255 de APM. Sin embargo, los SSD cruciales parecen funcionar a aproximadamente el 6% de la velocidad máxima en el nivel 128 de APM (arrancado con batería) en comparación con el nivel 254 de APM (arrancado con alimentación de CA).
La mala noticia es que no hay errores ni fallas aquí. La especificación ATA es lo suficientemente vaga como para que las SSD Crucial que se ejecutan súper lento en el modo APM 128 estén permitidas y cumplan con la especificación. Del mismo modo, una computadora portátil que adopta el nivel APM 80h (128) es perfectamente razonable. La especificación solo dice:
Tabla 106 - Niveles APM
campo COUNT Nivel
00h Reservado
01h Consumo mínimo de energía con el modo de espera
02h..7Fh Niveles intermedios de administración de energía con el modo de
espera
80h Consumo mínimo de energía sin el modo de espera 81h..FDh Niveles intermedios de administración de energía sin el modo de espera
FEh Rendimiento máximo
FFh Reservado
(De la especificación ATA )
Aquí está mi experiencia con un SSD Crucial MX300 arrancado con batería:
fuente
APM_level = not supported) en una PC de escritorio (es decir, nunca con batería). Debe haber razones más populares para las ralentizaciones de lectura.Es posible que desee verificar /etc/hdparm.conf donde puede configurar el nivel de apm para el modo de energía y batería.
Añadir
a /etc/hdparm.conf
fuente
Constantemente descubrí que era capaz de alcanzar las velocidades rápidas cuando encendí la computadora portátil mientras estaba enchufada. Si arranqué la computadora portátil mientras se estaba agotando la batería, y luego la enchufé, todavía estaba atascado en las velocidades lentas.
Esto puede haber sido algo específico para mi computadora portátil (Lenovo T420). Cambié todas las configuraciones de BIOS para no ahorrar energía, para obtener el máximo rendimiento; sin embargo, esto no le permitió tener velocidades rápidas cuando solo usaba la batería. Todavía tenía que enchufarme cuando arranqué para tener velocidades rápidas.
Otra nota: me pueden enchufar cuando arranque, y luego una vez que arranque, desconecte la computadora portátil. La computadora portátil mantendrá las velocidades rápidas hasta que se inicie la próxima vez.
RESPUESTA : Conéctese cuando arranque.
fuente
Utilice un kernel suficientemente nuevo (v4.15 +), intente usar med_power_with_dipm para su Crucial MX300.
LPM min_power no funciona bien para todos los controladores, si med_power_with_dipm funciona para usted, deberíamos usar una nueva peculiaridad para permitir que recurra a med_power_with_dipm cuando se selecciona min_power.
Además, presente un error en Launchpad, para que los ingenieros del kernel de Ubuntu puedan resolver el error o plantear el problema en sentido ascendente.
fuente