[opensuse-es] Disco duro de portatil
Saludos Desde ayer al arrancar el portátil suelta el siguiente mensaje: Your hard disk drive is failing! S.M.A.R.T. message: Device:/dev/sda, 1 offline uncorrectable sectors Una vez cerrado el mensaje se puede continuar usando el ordenador en condiciones, aparentemente, de toda normalidad. He hecho copia de respaldo de los datos. He pasado el comando smartctl -l error /dev/sda (al final pongo la salida). Me gustaría saber qué debo/puedo hacer y la gravedad de la situación. Salida del comando smartctl -l error /dev/sda: smartctl version 5.37 [i686-suse-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF READ SMART DATA SECTION === SMART Error Log Version: 1 ATA Error Count: 156 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 156 occurred at disk power-on lifetime: 5463 hours (227 days + 15 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 01:37:54.382 READ DMA 27 00 00 00 00 00 e0 00 01:37:54.374 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 01:37:54.374 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 01:37:54.368 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 01:37:49.402 READ NATIVE MAX ADDRESS EXT Error 155 occurred at disk power-on lifetime: 5463 hours (227 days + 15 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 01:37:54.382 READ DMA 27 00 00 00 00 00 e0 00 01:37:54.374 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 01:37:54.374 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 01:37:54.368 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 01:37:49.402 READ NATIVE MAX ADDRESS EXT Error 154 occurred at disk power-on lifetime: 5463 hours (227 days + 15 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 01:37:40.030 READ DMA 27 00 00 00 00 00 e0 00 01:37:35.085 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 01:37:35.084 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 01:37:35.076 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 01:37:49.402 READ NATIVE MAX ADDRESS EXT Error 153 occurred at disk power-on lifetime: 5463 hours (227 days + 15 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 01:37:40.030 READ DMA 27 00 00 00 00 00 e0 00 01:37:35.085 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 01:37:35.084 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 01:37:35.076 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 01:37:35.068 READ NATIVE MAX ADDRESS EXT Error 152 occurred at disk power-on lifetime: 5463 hours (227 days + 15 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 01:37:30.044 READ DMA 27 00 00 00 00 00 e0 00 01:37:35.085 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 01:37:35.084 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 01:37:35.076 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 01:37:35.068 READ NATIVE MAX ADDRESS EXT -- josep m solé
Josep m Solé escribió:
Saludos
Desde ayer al arrancar el portátil suelta el siguiente mensaje:
Your hard disk drive is failing! S.M.A.R.T. message: Device:/dev/sda, 1 offline uncorrectable sectors
Mis condolencias, tu disco duro ha muerto.. si puedes respaldar tus datos hazlo lo antes posible. -- "Morality is merely an interpretation of certain phenomena — more precisely, a misinterpretation." - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/ --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Josep m Solé escribió:
Saludos
Desde ayer al arrancar el portátil suelta el siguiente mensaje:
Your hard disk drive is failing! S.M.A.R.T. message: Device:/dev/sda, 1 offline uncorrectable sectors
Mis condolencias, tu disco duro ha muerto.. si puedes respaldar tus datos hazlo lo antes posible.
¿Por un único sector con fallo? No me parece a mi tan grave. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4XVetTMYHG2NR9URAjk7AJ98+ozjAucY0a/XJC5Pg5pAb8cy7wCfZu++ 1SmZBoF52mTjblVENLNa7ZI= =p6qh -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-19 a las 20:01 +0100, Josep m Solé escribió:
Desde ayer al arrancar el portátil suelta el siguiente mensaje:
¿Todas las veces que arranca?
Your hard disk drive is failing! S.M.A.R.T. message: Device:/dev/sda, 1 offline uncorrectable sectors
Eso es malo. Tienes sectores físicos del disco en mal estado. Si el disco ya ha agotado toda su capacidad de remapear esos sectores, debes reemplazarlo inmediatamente. Ayer es tarde. Si no están agotados, pues debes observar si se queda ahí, si no aumentan, o si aumentan. Si se queda estable, pues puede aguantar años: yo tengo discos con errores de esos que surgieron a los pocos meses de uso, y ya tienen veintemil horas de uso sin un sólo fallo. Antiguamente los discos te los vendían con una etiquetita listando qué sectores estaban mal. La simple existencia de sectores en mal estado no es catastrófico: es un evento habitual, esperable, y previsto. El fabricante ha apartado una serie de sectores donde se remapean los sectores en mal estado. Lo malo es si siguen y siguen apareciendo: llega un momento en que se desbordan los sectores que el fabricante previó para ese efecto, el disco irá a peor; es posible que haya habido un mal aterrizaje o que la cabeza esté dañada, y ya no te puedes fiar. Y por supuesto, indica que tiene más fallos que los que el fabricante pensó como admisible, lo cual en sí ya es muy malo.
Una vez cerrado el mensaje se puede continuar usando el ordenador en condiciones, aparentemente, de toda normalidad. He hecho copia de respaldo de los datos. He pasado el comando smartctl -l error /dev/sda (al final pongo la salida). Me gustaría saber qué debo/puedo hacer y la gravedad de la situación.
Salida del comando smartctl -l error /dev/sda:
Lo que hace falta es "-a", no "-l". - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4XgbtTMYHG2NR9URAhcmAKCY2dcuxH+616uOtZlQ2vqVrVtpEwCfZod4 n3Ug4OM2eHKJMdJd+j8nskc= =3EFs -----END PGP SIGNATURE-----
El Miércoles, 19 de Marzo de 2008 21:31, Carlos E. R. va escriure:
Salida del comando smartctl -l error /dev/sda:
Lo que hace falta es "-a", no "-l".
smartctl version 5.37 [i686-suse-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Seagate Momentus 42 family Device Model: ST94019A Serial Number: 3KW35B01 Firmware Version: 3.05 User Capacity: 40,007,761,920 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: ATA/ATAPI-6 T13 1410D revision 2 Local Time is: Wed Mar 19 23:00:58 2008 CET 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: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 119) The previous self-test completed having the read element of the test failed. Total time to complete Offline data collection: ( 426) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No 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. No General Purpose Logging support. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 31) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 056 051 034 Pre-fail Always - 20628490 3 Spin_Up_Time 0x0003 099 098 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 095 095 020 Old_age Always - 5263 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 080 060 030 Pre-fail Always - 103062525 9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 5467 10 Spin_Retry_Count 0x0013 100 100 034 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 097 097 020 Old_age Always - 3981 192 Power-Off_Retract_Count 0x0032 099 099 000 Old_age Always - 2336 193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 485046 194 Temperature_Celsius 0x0022 039 054 000 Old_age Always - 39 195 Hardware_ECC_Recovered 0x001a 056 051 000 Old_age Always - 20628490 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 1 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 1 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0 SMART Error Log Version: 1 ATA Error Count: 168 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 168 occurred at disk power-on lifetime: 5466 hours (227 days + 18 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 02:39:32.412 READ DMA 27 00 00 00 00 00 e0 00 02:39:32.412 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 02:39:32.403 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 02:39:27.387 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 02:39:27.387 READ NATIVE MAX ADDRESS EXT Error 167 occurred at disk power-on lifetime: 5466 hours (227 days + 18 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 02:39:32.412 READ DMA 27 00 00 00 00 00 e0 00 02:39:32.412 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 02:39:32.403 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 02:39:27.387 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 02:39:27.387 READ NATIVE MAX ADDRESS EXT Error 166 occurred at disk power-on lifetime: 5466 hours (227 days + 18 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 02:39:17.360 READ DMA 27 00 00 00 00 00 e0 00 02:39:17.360 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 02:39:17.352 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 02:39:27.387 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 02:39:27.387 READ NATIVE MAX ADDRESS EXT Error 165 occurred at disk power-on lifetime: 5466 hours (227 days + 18 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 02:39:17.360 READ DMA 27 00 00 00 00 00 e0 00 02:39:17.360 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 02:39:17.352 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 02:39:17.344 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 02:39:17.343 READ NATIVE MAX ADDRESS EXT Error 164 occurred at disk power-on lifetime: 5466 hours (227 days + 18 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 02:39:17.360 READ DMA 27 00 00 00 00 00 e0 00 02:39:17.360 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 02:39:17.352 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 02:39:17.344 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 02:39:17.343 READ NATIVE MAX ADDRESS EXT SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 70% 5464 19815269 # 2 Short offline Completed: read failure 90% 5464 19815269 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. -- josep m solé
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-19 a las 22:18 +0100, Josep m Solé escribió:
=== START OF INFORMATION SECTION === Model Family: Seagate Momentus 42 family Device Model: ST94019A
...
SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 056 051 034 Pre-fail Always - 20628490 3 Spin_Up_Time 0x0003 099 098 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 095 095 020 Old_age Always - 5263 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
bien
7 Seek_Error_Rate 0x000f 080 060 030 Pre-fail Always - 103062525 9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 5467 10 Spin_Retry_Count 0x0013 100 100 034 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 097 097 020 Old_age Always - 3981 192 Power-Off_Retract_Count 0x0032 099 099 000 Old_age Always - 2336 193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 485046 194 Temperature_Celsius 0x0022 039 054 000 Old_age Always - 39 195 Hardware_ECC_Recovered 0x001a 056 051 000 Old_age Always - 20628490
Esto... ? Ah, vale, no importa.
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 1 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 1
Éste es el error que te ha cantado.
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0
SMART Error Log Version: 1 ATA Error Count: 168 (device log contains only the most recent five errors)
SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 70% 5464 19815269 # 2 Short offline Completed: read failure 90% 5464 19815269
Error de lectura en ese sector. Creo que hay que forzar el remapeo de sector. Eso se hace tratando de escribir en el sector en cuestión, pero ahora mismo no sé como hacerlo teniendo el LBA. Intenta lo siguiente: lee todo el disco con dd escribiendo en null. Fallará en un punto: anotalo, y escribe encima lo que sea. Esa es la manera bruta, porque pierdes un fichero, sin saber cual. La manera ideal es averiguar qué fichero es el que está ahí, grabarlo en otro sitio, grabar encima del sector malo, y borrarlo. Lo que no sé es cómo averiguar qué fichero es (en vfat sabía), salvo leerlos todos y ver cual falla (si no falla ninguno, es que está en un sector no asignado). Una manera bruta y lenta, pero más segura, es copiar todo el disco a otro disco, reformatearlo con comprobación de sectores (escribiendo), y finalmente volver a grabar los datos. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4ZM6tTMYHG2NR9URAg3/AJ9P5UDQ+fltqTaMGHANcBuOCObS3QCfXPgu bQyfX25WpRzlPAhNAZ99bmI= =ZjwC -----END PGP SIGNATURE-----
2008/3/19, Josep m Solé:
=== START OF INFORMATION SECTION === Model Family: Seagate Momentus 42 family Device Model: ST94019A Serial Number: 3KW35B01 Firmware Version: 3.05 User Capacity: 40,007,761,920 bytes
¿Es un equipo del que no puedes prescindir? Toma nota del modelo y las características y busca un disco nuevo. Creo que no merece la pena estar pendiente cada día de una posible pérdida de datos o de no saber si al día siguiente se va a encender o no :-/
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 485046
Hum... este valor ¿no son muchos ciclos? Es que, recuerdo que hubo un problema con los discos duros de portátiles, no sé en qué quedó (si era bug o no) relacionado con este tema de los ciclos y ese valor me parece muy alto :-/
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 1 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 1
Pero si es un equipo "prescindible", prueba a pasar de nuevo el test que falla para ver si puede corregir el error automáticamente o si se trata de un error esporádico: smartctl -t offline /dev/sda Y comprueba si te aparece de nuevo el error. ¿Tienes algún otro sistema operativo instalado en ese disco? Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-19 a las 23:55 +0100, Camaleón escribió:
¿Es un equipo del que no puedes prescindir? Toma nota del modelo y las características y busca un disco nuevo.
Creo que no merece la pena estar pendiente cada día de una posible pérdida de datos o de no saber si al día siguiente se va a encender o no :-/
Depende :-p
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 485046
Hum... este valor ¿no son muchos ciclos?
Es que, recuerdo que hubo un problema con los discos duros de portátiles, no sé en qué quedó (si era bug o no) relacionado con este tema de los ciclos y ese valor me parece muy alto :-/
¿Era esa variable? Se trata del aparcamiento del cabezal durante el uso, pero no sé que variable lo mide. Si es esa, entonces es alto y la cabeza puede estar dañada o cercana a ello. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4Z72tTMYHG2NR9URAsv4AJ4uthI0zsQncCXFAmCwGBRE95KVawCfaCN9 IRwiz3UjumsGgSmOOll2xkQ= =zOaX -----END PGP SIGNATURE-----
El Miércoles, 19 de Marzo de 2008 23:55, Camaleón va escriure:
Pero si es un equipo "prescindible", prueba a pasar de nuevo el test que falla para ver si puede corregir el error automáticamente o si se trata de un error esporádico:
smartctl -t offline /dev/sda Aquí viene la salida: smartctl version 5.37 [i686-suse-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION === Model Family: Seagate Momentus 42 family Device Model: ST94019A Serial Number: 3KW35B01 Firmware Version: 3.05 User Capacity: 40,007,761,920 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: ATA/ATAPI-6 T13 1410D revision 2 Local Time is: Thu Mar 20 09:36:26 2008 CET 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: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 119) The previous self-test completed having the read element of the test failed. Total time to complete Offline data collection: ( 426) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No 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. No General Purpose Logging support. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 31) minutes. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 055 051 034 Pre-fail Always - 37977019 3 Spin_Up_Time 0x0003 099 098 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 095 095 020 Old_age Always - 5263 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 080 060 030 Pre-fail Always - 103162040 9 Power_On_Hours 0x0032 094 094 000 Old_age Always - 5469 10 Spin_Retry_Count 0x0013 100 100 034 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 097 097 020 Old_age Always - 3983 192 Power-Off_Retract_Count 0x0032 099 099 000 Old_age Always - 2336 193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 485058 194 Temperature_Celsius 0x0022 039 054 000 Old_age Always - 39 195 Hardware_ECC_Recovered 0x001a 055 051 000 Old_age Always - 37977019 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 1 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 1 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0000 100 253 000 Old_age Offline - 0 202 TA_Increase_Count 0x0032 100 253 000 Old_age Always - 0 SMART Error Log Version: 1 ATA Error Count: 168 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 168 occurred at disk power-on lifetime: 5466 hours (227 days + 18 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 02:39:32.412 READ DMA 27 00 00 00 00 00 e0 00 02:39:32.412 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 02:39:32.403 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 02:39:27.387 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 02:39:27.387 READ NATIVE MAX ADDRESS EXT Error 167 occurred at disk power-on lifetime: 5466 hours (227 days + 18 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 02:39:32.412 READ DMA 27 00 00 00 00 00 e0 00 02:39:32.412 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 02:39:32.403 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 02:39:27.387 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 02:39:27.387 READ NATIVE MAX ADDRESS EXT Error 166 occurred at disk power-on lifetime: 5466 hours (227 days + 18 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 02:39:17.360 READ DMA 27 00 00 00 00 00 e0 00 02:39:17.360 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 02:39:17.352 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 02:39:27.387 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 02:39:27.387 READ NATIVE MAX ADDRESS EXT Error 165 occurred at disk power-on lifetime: 5466 hours (227 days + 18 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 02:39:17.360 READ DMA 27 00 00 00 00 00 e0 00 02:39:17.360 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 02:39:17.352 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 02:39:17.344 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 02:39:17.343 READ NATIVE MAX ADDRESS EXT Error 164 occurred at disk power-on lifetime: 5466 hours (227 days + 18 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- c8 00 08 5f 5b 2e e1 00 02:39:17.360 READ DMA 27 00 00 00 00 00 e0 00 02:39:17.360 READ NATIVE MAX ADDRESS EXT ec 00 00 00 00 00 a0 02 02:39:17.352 IDENTIFY DEVICE ef 03 42 00 00 00 a0 02 02:39:17.344 SET FEATURES [Set transfer mode] 27 00 00 00 00 00 e0 00 02:39:17.343 READ NATIVE MAX ADDRESS EXT SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 70% 5464 19815269 # 2 Short offline Completed: read failure 90% 5464 19815269 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.
Y comprueba si te aparece de nuevo el error.
¿Tienes algún otro sistema operativo instalado en ese disco?
No. Sólo Opensuse 10.3. (Tengo un windows xp en Virtualbox).
Saludos,
-- josep m solé
2008/3/20, Josep m Solé:
Aquí viene la salida:
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
Que este valor esté a cero es buena señal...
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 1 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 1
Pero te sigue apareciendo el error.
40 51 00 65 5b 2e e1 Error: UNC at LBA = 0x012e5b65 = 19815269
Sólo tienes uno y localizado.
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 70% 5464 19815269 # 2 Short offline Completed: read failure 90% 5464 19815269
Hum... analicemos un poco: - Tienes un error localizado en un sólo sector del disco duro. - Si no lo reparas y sigues usando el equipo, puede ir a peor (más errores) o puede que un día se quede colgado el equipo al intentar leer en ese sector, o incluso que pierdas datos... - Importancia del equipo: a) Si es un portátil de uso "vital", cambia el disco. b) Si puedes permitirte que falle el disco duro en cualquier momento o tener bloqueos esporádicos, puedes intentar reparar ese único sector que tienes dañado... Si es b), en la página de smartmoontools hay un procedimiento* para hacerlo (la situación parece la misma), pero ojo, creo que es para ext2 / ext3 no para reiserfs (¿se podría adaptar?) y bueno ya sabes que el resultado podría ser malo, muy malo o terrible >:-) o... podrías eliminar el error y convivir con el disco un tiempo más... * http://smartmontools.sourceforge.net/BadBlockHowTo.txt Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Sólo tienes uno y localizado.
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 70% 5464 19815269 # 2 Short offline Completed: read failure 90% 5464 19815269
Hum... analicemos un poco:
- Tienes un error localizado en un sólo sector del disco duro. - Si no lo reparas y sigues usando el equipo, puede ir a peor (más errores) o puede que un día se quede colgado el equipo al intentar leer en ese sector, o incluso que pierdas datos... - Importancia del equipo:
a) Si es un portátil de uso "vital", cambia el disco. b) Si puedes permitirte que falle el disco duro en cualquier momento o tener bloqueos esporádicos, puedes intentar reparar ese único sector que tienes dañado...
¡Pero que manía teneis con cambiar el disco por un mísero error! Mira el mio: Error 325 occurred at disk power-on lifetime: 4275 hours (178 days + 3 hours) When the command that caused the error occurred, the device was active or idle. ... 40 51 64 9c 16 70 51 Error: UNC at LBA = 0x0170169c = 24123036 ... SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 9 Power_On_Hours 0x0032 076 076 000 Old_age Always - 21241 ... 195 Hardware_ECC_Recovered 0x001a 100 253 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 Traduzco: el error se produjo a las 4275, y el disco tiene ahora 21241 horas de uso, sin más problemas. ¡Un sólo error, o una docena, no tienen significación alguna! A ver. Si no lo reparas, no pasa nada: ni va a peor ni mejora, ni por "arreglarlo" ni por dejarlo. Pasa, obviamente, que el error saltará en los registros con frecuencia, y que al intentar leer de ahí el disco se atascará durante unos segundos congelando el sistema durante los ¿5? reintentos de rigor. El que vaya a peor es independiente de "arreglarlo". Que no se arregla, por cierto: se remapea. Si va a peor entonces sí es seguro que haya que cambiar el disco.
Si es b), en la página de smartmoontools hay un procedimiento* para hacerlo (la situación parece la misma), pero ojo, creo que es para ext2 / ext3 no para reiserfs (¿se podría adaptar?) y bueno ya sabes que el resultado podría ser malo, muy malo o terrible >:-) o... podrías eliminar el error y convivir con el disco un tiempo más...
El procedimiento es más o menos el que yo dije ayer, pero explicado. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4lRitTMYHG2NR9URAuoBAJ9Vk92G7nk/ONaGvsK/mtoCQ0kHEQCeJW7/ k6XLiPkXG+Z0JNJECRLfUWU= =/X8s -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-20 a las 08:39 +0100, Josep m Solé escribió:
Pero si es un equipo "prescindible", prueba a pasar de nuevo el test que falla para ver si puede corregir el error automáticamente o si se trata de un error esporádico:
smartctl -t offline /dev/sda
smartctl --test=long /dev/hda (Executes extended disk self-test) Espera el tiempo que te dice, y busca los resultados. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4lS9tTMYHG2NR9URAg1fAJwI/vKFTAp+4m8FlrIXWK3lq0GXMQCfZqzS ETPMg6VydZHQk32SwI4L/Js= =pu4o -----END PGP SIGNATURE-----
El 20/03/08, Carlos E. R. escribió:
¡Pero que manía teneis con cambiar el disco por un mísero error!
<modo malo-pero-que-muy-malo on> Año 1962... "¡Pero qué manía en utilizar 4 dígitos para el año, si con dos es suficiente y lo que se ahorra de memoria...!" Eso es lo que yo llamo de "mentalidad programador": centrarse en un mensaje concreto o en un error determinado y considerarlo "como un todo". Los programadores suelen ser especialistas en el método "inductivo" (reduciendo todos los problemas a uno sólo). En cambio, si un ingeniero ve una estructura con un movimiento "extraño" o "inusual", o una "pequeña grieta", es posible que primero la apuntale y la asegure, pero al día siguiente la tira, completa, si el coste de hacerlo es razonable. Hay mucho en juego :-/. Más tarde, es posible que le interese conocer el origen del problema y realizará todo tipo de análisis (terreno, vigas, estado del material, volverá a pedir los cálculos de todo tipo de hipótesis...) para ver qué ha fallado. Pero la estructura que presentaba un comportamiento "aleatorio, errático y no predecible" ya no está, la ha quitado. Y sí, claro que depende de la "utilidad" que se le dé a ese disco duro o a ese equipo y su "importancia"... al menos así lo creo. Si un componente mecánico (el más importante, al menos desde mi punto de vista, de un ordenador) falla, te da un error, te avisa... cámbialo, sustitúyelo y pon uno nuevo (estamos hablando de, como mucho, 90€). Si tienes interés, haz las pruebas que quieras, pero sin que ese error te pueda "jorobar" nada. Ya lo dice el refrán: "guerra avisada no mata soldado" :-)
Mira el mio:
(Tu disco será de un sobremesa, supongo...). Y en la misma página de smatmontools hay ejemplos de resultados de análisis: http://smartmontools.sourceforge.net/#sampleoutput
Error 325 occurred at disk power-on lifetime: 4275 hours (178 days + 3 hours)
When the command that caused the error occurred, the device was active or idle.
... 40 51 64 9c 16 70 51 Error: UNC at LBA = 0x0170169c = 24123036
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
Tienes los valores a cero :-?
Traduzco: el error se produjo a las 4275, y el disco tiene ahora 21241 horas de uso, sin más problemas.
¡Un sólo error, o una docena, no tienen significación alguna!
"Azar" y "casualidad" también son variables a tener en cuenta, no lo olvides ;-). Es posible que el tuyo funcione... o no. Al igual que es posible que el suyo (disco duro de un portátil) funcione (si lo repara) o no... o que deje de salirle el mensaje de aviso y al día siguiente no pueda iniciar el equipo. Es una ruleta rusa, no sabes ni qué, ni cuándo, ni si puede fallar.
Si no lo reparas, no pasa nada: ni va a peor ni mejora, ni por "arreglarlo" ni por dejarlo. Pasa, obviamente, que el error saltará en los registros con frecuencia, y que al intentar leer de ahí el disco se atascará durante unos segundos congelando el sistema durante los ¿5? reintentos de rigor.
Y algo más... se pueden perder datos.
El que vaya a peor es independiente de "arreglarlo". Que no se arregla, por cierto: se remapea. Si va a peor entonces sí es seguro que haya que cambiar el disco.
¿Y cuándo se sabe que "va a peor"? ¿2, 3, 10, 50 sectores defectuosos...? Ese es el problema >:-)
El procedimiento es más o menos el que yo dije ayer, pero explicado.
Para ReiserFS también está (no lo vi antes): http://smartmontools.sourceforge.net/badblockhowto.html Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-20 a las 15:56 +0100, Camaleón escribió:
En cambio, si un ingeniero ve una estructura con un movimiento "extraño" o "inusual", o una "pequeña grieta", es posible que primero la apuntale y la asegure, pero al día siguiente la tira, completa, si el coste de hacerlo es razonable. Hay mucho en juego :-/.
Huy, al coche se le ha encendido una luz roja. Tíralo y compra otro. >:-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4orVtTMYHG2NR9URAnODAJwLf8nZFxVfkK+LIHsPMNE+vFRp9ACeI3eg K3QFhU6Sd3V5lVwk0zPgByg= =k0RZ -----END PGP SIGNATURE-----
El 20/03/08, Carlos E. R. escribió:
Huy, al coche se le ha encendido una luz roja. Tíralo y compra otro. >:-)
Obviamente, el mensaje quería ir un pelín más allá del mero hecho de "disco roto o disco en buen estado" y como has elegido la analogía con el coche, te la sigo :-P. Si ves que se enciende una luz roja, te vas al taller y ahí revisan el coche. Si hay algo que falla, lo cambian. Te "clavan" el presupuesto de la pieza nueva (del fabricante). Lo que no te van a decir es: a) "Mire, esta luz roja se ha encendido... pero es posible que no pase nada, verá, a mi vecino se le encendió y pudo andar con el vehículo 100 Km. más... hasta que tuvo que llamar a la grúa porque lo dejó tirado a medio camino... pero quizá ud. tenga más suerte... si quiere, le desconecto el cable para que no le moleste la luz mientras conduce" Ni... b) "Oye, mira, hacemos lo siguiente, te pongo esta pieza de segunda mano que he sacado de un desguace del que conozco a la hermana de mi colega y te lo soluciono por la mitad del precio oficial..."
:-)
(hum... bueno, vale, el caso b) se da más :-P) El fondo de todo esto... lo que quiero decir... es que el test de smart está bien, pero te deja con la incógnita del "qué hago, qué me dice exactamente el resultado de la prueba y qué tengo que hacer... está fallando el disco o no y cuánto tiempo le queda o si tiene solución y en ese caso, cómo lo puedo solucionar". Que, al fin y al cabo, es lo mismo que no decirte nada :-/. Y si hay algo que no debería hacer un sistema informático (un análisis en este caso) es dejarte con la duda... o sí --> está roto y hay que cambiarlo, o no --> está todo correcto. Y ante el aviso de un pinchazo, ¿dejas la rueda pinchada y sigues "a revienta caballo" a verlas venir... o te paras y la cambias en cuanto tienes oportunidad? Los avisos (pitido, mensaje, error, ruido, fiebre...), en informática, en mecánica, en electrónica, en ingeniería, en medicina... no se deben pasar por alto, nunca: son "síntomas". Y si no se puede diagnosticar el problema con exactitud, lo mejor, siempre que sea posible, es cambiar la pieza que falla, porque lo demás, no dejan de ser "parches". Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-20 a las 23:10 +0100, Camaleón escribió:
El 20/03/08, Carlos E. R. escribió:
Huy, al coche se le ha encendido una luz roja. Tíralo y compra otro. >:-)
Obviamente, el mensaje quería ir un pelín más allá del mero hecho de "disco roto o disco en buen estado" y como has elegido la analogía con el coche, te la sigo :-P.
Si ves que se enciende una luz roja, te vas al taller y ahí revisan el coche. Si hay algo que falla, lo cambian. Te "clavan" el presupuesto de la pieza nueva (del fabricante).
Si el coche es bueno tendrá un ordenador de a bordo que te dirá: puede usted continuar viaje, no tiene importancia, o llame a la grua ya mismo. O tendrá veinte bombillitas, y una de ellas será la de "parada inmediata".
El fondo de todo esto... lo que quiero decir... es que el test de smart está bien, pero te deja con la incógnita del "qué hago, qué me dice exactamente el resultado de la prueba y qué tengo que hacer... está fallando el disco o no y cuánto tiempo le queda o si tiene solución y en ese caso, cómo lo puedo solucionar".
El test te dice que no hay nada que esté mal, salvo un único sector que ha fallado. Y no te puede decir porqué, porque en PCs no existen pruebas y registros exhaustivos. Por ejemplo, podría decir que hay un error de comprobación de CRC: podría grabar los mismos datos de nuevo encima (salvo que no sabe cuales son los correctos), leer de nuevo, y ver que están bien. O podría ver que unos dias después se han borrado. O podría medir las magnetizaciones del sector y ver si están débiles. De eso no hay nada.
Que, al fin y al cabo, es lo mismo que no decirte nada :-/. Y si hay algo que no debería hacer un sistema informático (un análisis en este caso) es dejarte con la duda... o sí --> está roto y hay que cambiarlo, o no --> está todo correcto.
Prueba con "--health", verás como te dice que está bien.
Y ante el aviso de un pinchazo, ¿dejas la rueda pinchada y sigues "a revienta caballo" a verlas venir... o te paras y la cambias en cuanto tienes oportunidad?
Depende. Si estoy en un coche con dos mil ruedas, sigo camino tan campante.
Los avisos (pitido, mensaje, error, ruido, fiebre...), en informática, en mecánica, en electrónica, en ingeniería, en medicina... no se deben pasar por alto, nunca: son "síntomas". Y si no se puede diagnosticar el problema con exactitud, lo mejor, siempre que sea posible, es cambiar la pieza que falla, porque lo demás, no dejan de ser "parches".
Cambiar la pieza, exacto: "cambias" el sector dañado por otro sector de los de repuesto. Lo acabas de decir... cambias la pieza, no el coche entero. Es un procedimiento previsto por el fabricante del disco. Es el (los) que han diseñado el sistema operativo los que no han hecho una herramienta para hacer ese cambio con un simple click (en windows sí que existen). Pero el disco lleva sectores de respuesto, porque el fabricante sabe que es _normal_ que fallen unos cuantos. Puede ser por simple ruido, un fallo aleatorio que se arregla volviendo a escribir. O la superficie puede estar mal (un poro) y no retiene la escritura, en cuyo caso se cambia por otro sector. Si es la cabeza la que está mal, empezará a fallar con un montón de sectores: y eso sí que es grave. ¿Pero un único sector? No. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4uhDtTMYHG2NR9URAqMcAJ47iVZl0EsI5asww+Z2UFOr4apeTgCeM4EU d5RdaoWWePUx7FnAPXiGJrk= =XXzN -----END PGP SIGNATURE-----
El 20/03/08, Carlos E. R. escribió:
Si el coche es bueno
Muy bueno... y de menos de ¿4 años? >:-)
tendrá un ordenador de a bordo que te dirá: puede usted continuar viaje, no tiene importancia, o llame a la grua ya mismo. O tendrá veinte bombillitas, y una de ellas será la de "parada inmediata".
¿Ya estamos en el año 3000 para que el coche nos diga si viajamos
seguros? Yo creo que no, como mucho, te avisa
El test te dice que no hay nada que esté mal, salvo un único sector que ha fallado. Y no te puede decir porqué, porque en PCs no existen pruebas y registros exhaustivos.
Por ejemplo, podría decir que hay un error de comprobación de CRC: podría grabar los mismos datos de nuevo encima (salvo que no sabe cuales son los correctos), leer de nuevo, y ver que están bien. O podría ver que unos dias después se han borrado. O podría medir las magnetizaciones del sector y ver si están débiles.
De eso no hay nada.
Lo cual nos deja igual que si tuviéramos smart desactivado.
Prueba con "--health", verás como te dice que está bien.
¿Has visto que algún reporte de smatmoontools dice "test passed" y la cantidad de errores que tiene? :-/ De eso sólo no te puedes fiar. (failing self-tests. Note Current_Pending_Sector raw value and Uncorrectable (UNC) read errors) http://smartmontools.sourceforge.net/examples/MAXTOR-10.txt
Cambiar la pieza, exacto: "cambias" el sector dañado por otro sector de los de repuesto.
Lo acabas de decir... cambias la pieza, no el coche entero.
Eso es un parche, no una solución. Estás "parcheando", tapando un socavón. Puede salir bien... o mal.
Es un procedimiento previsto por el fabricante del disco. Es el (los) que han diseñado el sistema operativo los que no han hecho una herramienta para hacer ese cambio con un simple click (en windows sí que existen). Pero el disco lleva sectores de respuesto, porque el fabricante sabe que es _normal_ que fallen unos cuantos.
Si está contemplado por el fabricante, que lo repare (que es lo que hacen los disco). Si no lo ha podido reparar "automáticamente" es por algo.
Puede ser por simple ruido, un fallo aleatorio que se arregla volviendo a escribir. O la superficie puede estar mal (un poro) y no retiene la escritura, en cuyo caso se cambia por otro sector.
O puedes ser un síntoma de algo peor... ¡es que no se puede saber!
Si es la cabeza la que está mal, empezará a fallar con un montón de sectores: y eso sí que es grave. ¿Pero un único sector? No.
Pero eso es una apreciación subjetiva. Dime un documento del fabricante del disco que diga de forma expresa que "un sólo error de smart del tipo Current_Pending_Sector y Offline_Uncorrectable" no implique merma alguna en el estado del disco duro y que puede ser "obviado" sin temor alguno. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-20 a las 15:56 +0100, Camaleón escribió:
El 20/03/08, Carlos E. R. escribió:
¡Pero que manía teneis con cambiar el disco por un mísero error!
<modo malo-pero-que-muy-malo on>
Año 1962...
"¡Pero qué manía en utilizar 4 dígitos para el año, si con dos es suficiente y lo que se ahorra de memoria...!"
En el año 62, en que las memorias eran unos nucleos de ferrita diminutos con unos hilos de cobre que se pasaban a mano por unas hilanderas del sureste asiatico o de Filipinas muy hacendosas, y probablemente muy jovencitas (por las manos pequeñas y la buena vista), y dado que una placa de 1 kilobyte costaba una pasta, el año se ponía con dos cifras, y gracias. Que en los años 90 el windows usara dos digitos, eso tiene delito.
Eso es lo que yo llamo de "mentalidad programador": centrarse en un mensaje concreto o en un error determinado y considerarlo "como un todo". Los programadores suelen ser especialistas en el método "inductivo" (reduciendo todos los problemas a uno sólo).
En cambio, si un ingeniero ve una estructura con un movimiento "extraño" o "inusual", o una "pequeña grieta", es posible que primero la apuntale y la asegure, pero al día siguiente la tira, completa, si el coste de hacerlo es razonable. Hay mucho en juego :-/.
Si un ingeniero hace un puente colgante con un millon de fibras, y el ordenador de control le dice que se ha roto una, simplemente toma nota y reduce la carga máxima en una millonésima.
Mira el mio:
40 51 64 9c 16 70 51 Error: UNC at LBA = 0x0170169c = 24123036
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0
Tienes los valores a cero :-?
Sí. Lo puedes ver en el comentario de la página que pusiste antes: el hardware del disco volvió a grabar ese sector, no dió error, y por tanto no lo movió de sitio. Hubo una serie de errores, que están registrados en el registro de errores; eran varios sectores que daban error de lectura. Grabé los datos en otro sitio, escribí encima en todos los sectores, corrí el badblocks una o dos veces, reformatee, y volví a reponer los datos. Sigue funcionando tan campante varios años después.
Traduzco: el error se produjo a las 4275, y el disco tiene ahora 21241 horas de uso, sin más problemas.
¡Un sólo error, o una docena, no tienen significación alguna!
"Azar" y "casualidad" también son variables a tener en cuenta, no lo olvides ;-).
En electrónica existe el azar, está previsto. Se le llama "ruido".
Es posible que el tuyo funcione... o no. Al igual que es posible que el suyo (disco duro de un portátil) funcione (si lo repara) o no... o que deje de salirle el mensaje de aviso y al día siguiente no pueda iniciar el equipo. Es una ruleta rusa, no sabes ni qué, ni cuándo, ni si puede fallar.
Para eso se hacen las copias de seguridad. Te puede fallar un disco de golpe aunque no te avise de nada.
Si no lo reparas, no pasa nada: ni va a peor ni mejora, ni por "arreglarlo" ni por dejarlo. Pasa, obviamente, que el error saltará en los registros con frecuencia, y que al intentar leer de ahí el disco se atascará durante unos segundos congelando el sistema durante los ¿5? reintentos de rigor.
Y algo más... se pueden perder datos.
Nop. Ya hemos hablado de la copia de seguridad.
El que vaya a peor es independiente de "arreglarlo". Que no se arregla, por cierto: se remapea. Si va a peor entonces sí es seguro que haya que cambiar el disco.
¿Y cuándo se sabe que "va a peor"? ¿2, 3, 10, 50 sectores defectuosos...? Ese es el problema >:-)
Pues cuando aumentan. Haces un chequeo, tienes uno. Haces otro, tienes tres. Haces otro, tienes seis...
El procedimiento es más o menos el que yo dije ayer, pero explicado.
Para ReiserFS también está (no lo vi antes):
Este párrafo es muy interesante y confirma lo que digo: SCSI disks expect unrecoverable errors to be fixed manually using the REASSIGN BLOCKS SCSI command since loss of data is involved. It is possible that an operating system or a file system could issue the REASSIGN BLOCKS command itself but the authors are unaware of any examples. The REASSIGN BLOCKS command will reassign one or more blocks, attempting to (partially ?) recover the data (a forlorn hope at this stage), fetch an unused spare sector from the current zone while adding the damaged old sector to the GLIST (hence the name "grown" list). The contents of the GLIST may not be that interesting but smartctl prints out the number of entries in the grown list and if that number grows quickly, the disk may be approaching the end of its useful life. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4u/ltTMYHG2NR9URAqggAJ9V4FMIqejdkmEF4MlfASIvte7N4gCeLeia Fm/vHzYlNDuRWccUJEEuqlo= =S8La -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-21 a las 00:11 +0100, Camaleón escribió:
El 20/03/08, Carlos E. R. escribió:
Si el coche es bueno
Muy bueno... y de menos de ¿4 años? >:-)
tendrá un ordenador de a bordo que te dirá: puede usted continuar viaje, no tiene importancia, o llame a la grua ya mismo. O tendrá veinte bombillitas, y una de ellas será la de "parada inmediata".
¿Ya estamos en el año 3000 para que el coche nos diga si viajamos seguros? Yo creo que no, como mucho, te avisa
y ahí te apañes...
Que va, ya los hay que te recuerdan que te pongas el cinturón. Hay algunos que de repente no aceleran; vale, pues paras, sales y cierras, entras, arrancas, y tienes veinte caballos más.
El test te dice que no hay nada que esté mal, salvo un único sector que ha fallado. Y no te puede decir porqué, porque en PCs no existen pruebas y registros exhaustivos.
Por ejemplo, podría decir que hay un error de comprobación de CRC: podría grabar los mismos datos de nuevo encima (salvo que no sabe cuales son los correctos), leer de nuevo, y ver que están bien. O podría ver que unos dias después se han borrado. O podría medir las magnetizaciones del sector y ver si están débiles.
De eso no hay nada.
Lo cual nos deja igual que si tuviéramos smart desactivado.
Pues no, no te deja igual. Si tuvieras un disco de los antiguos es que no te enterabas de los fallos, hasta que petaba del todo. Y por cierto: el format del msdos lo sabía que los sectores podían fallar, y los comprobaba todos al formatear, marcando en el mapa FAT cuales eran los malos. Y el programa de comprobación podía ir marcando los que iban apareciendo con el tiempo: y no por eso te decía que tenías que cambiar el disco. Era una evolución esperada.
Prueba con "--health", verás como te dice que está bien.
¿Has visto que algún reporte de smatmoontools dice "test passed" y la cantidad de errores que tiene? :-/ De eso sólo no te puedes fiar.
(failing self-tests. Note Current_Pending_Sector raw value and Uncorrectable (UNC) read errors) http://smartmontools.sourceforge.net/examples/MAXTOR-10.txt
Ese es un disco con 18875 horas de uso, con sólo 54 apagados. O sea, de uso continuo. Tiene algunos sectores remapeados. Nada grave en el sentido de "emergencia", pero yo iría cambiandolo si la evolución de sectores malos ha sido reciente.
Cambiar la pieza, exacto: "cambias" el sector dañado por otro sector de los de repuesto.
Lo acabas de decir... cambias la pieza, no el coche entero.
Eso es un parche, no una solución. Estás "parcheando", tapando un socavón. Puede salir bien... o mal.
No es un parche de un socavón. Es una reparación prevista por el fabricante, lo mismo que el fabricante de ruedas ha previsto que puedas ponerle parches al neumático.
Es un procedimiento previsto por el fabricante del disco. Es el (los) que han diseñado el sistema operativo los que no han hecho una herramienta para hacer ese cambio con un simple click (en windows sí que existen). Pero el disco lleva sectores de respuesto, porque el fabricante sabe que es _normal_ que fallen unos cuantos.
Si está contemplado por el fabricante, que lo repare (que es lo que hacen los disco). Si no lo ha podido reparar "automáticamente" es por algo.
Por la sencilla razón de que el disco no sabe si el sector está asignado y contiene datos de un fichero. No puede tomar esa responsabilidad en un error de lectura no corregible (quiere decir hay más bits mal que los previstos por los códigos de corrección de errores). Es responsabilidad del sistema operativo corregir los errores de sectores malos descubiertos durante la lectura, no del hardware del disco; eso sí, el sistema puede usar los recursos del hardware. Pero como dice en ese enlace que pasaste, no se sabe que eso lo hayan hecho. Pero sí hay programas que efectúan esa corrección. En windows.
Puede ser por simple ruido, un fallo aleatorio que se arregla volviendo a escribir. O la superficie puede estar mal (un poro) y no retiene la escritura, en cuyo caso se cambia por otro sector.
O puedes ser un síntoma de algo peor... ¡es que no se puede saber!
No, no lo puedes saber. Por eso mi procedimiento preferido es reformatear y hacer un chequeo completo de sectores r/w, lo cual es tan bruto que hace saltar una cascada de errores si el disco está falluto.
Si es la cabeza la que está mal, empezará a fallar con un montón de sectores: y eso sí que es grave. ¿Pero un único sector? No.
Pero eso es una apreciación subjetiva. Dime un documento del fabricante del disco que diga de forma expresa que "un sólo error de smart del tipo Current_Pending_Sector y Offline_Uncorrectable" no implique merma alguna en el estado del disco duro y que puede ser "obviado" sin temor alguno.
No lo es, es know-how. Dime otro documento del fabricante donde te diga que tires el disco si tienes esa misma combinación de errores. Si lo buscas por ahí lo encontrarás. Yo me acuerdo de cuando los discos duros venían con una etiqueta firmada por el fabricante que te decía que "los sectores xxx yyy y zzz están mal, no los use". Y te cobraban igual si tenía cinco sectores mal como ninguno - y eran discos con sólo veinte megas, la perdida de un sector era significativa. ¿Porqué sino van los fabricantes a poner sectores de repuesto sino es para usarlos? Saben que el disco va a tener sectores malos tarde o temprano, y no por eso te lo van a cambiar. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH4wP2tTMYHG2NR9URAj68AJ9VkAGj6JpoiXTPATfcsz2iVeLlKACfcrYr XuUPzdcArd/0gxXsnxSWgXw= =lpRd -----END PGP SIGNATURE-----
El 21/03/08, Carlos E. R. escribió:
En el año 62, en que las memorias eran unos nucleos de ferrita diminutos con unos hilos de cobre que se pasaban a mano por unas hilanderas del sureste asiatico o de Filipinas muy hacendosas, y probablemente muy jovencitas (por las manos pequeñas y la buena vista), y dado que una placa de 1 kilobyte costaba una pasta, el año se ponía con dos cifras, y gracias.
Que en los años 90 el windows usara dos digitos, eso tiene delito.
Más que una limitación por los componentes, el error fue pensar "que no tendría ningún efecto secundario y que no pasaría nada...". Una mentalidad "ahorrativa" puede ser catastrófica. Pero no tiene mayor importancia, la historia está llena de cálculos erróneos que han conllevado desde batallas perdidas hasta millones perdidos. Son decisiones que hay que tomar y donde no siempre se acierta :-).
Si un ingeniero hace un puente colgante con un millon de fibras, y el ordenador de control le dice que se ha roto una, simplemente toma nota y reduce la carga máxima en una millonésima.
Dependerá de la importancia que tenga sobre el conjunto "esa fibra". La decisión se basará en si puede degenerar en la rotura de otras fibras u otros elementos de la estructura. Se llama "indeterminación".
Sí. Lo puedes ver en el comentario de la página que pusiste antes: el hardware del disco volvió a grabar ese sector, no dió error, y por tanto no lo movió de sitio.
Hubo una serie de errores, que están registrados en el registro de errores; eran varios sectores que daban error de lectura. Grabé los datos en otro sitio, escribí encima en todos los sectores, corrí el badblocks una o dos veces, reformatee, y volví a reponer los datos. Sigue funcionando tan campante varios años después.
Lo cual es una opción, que además explican en la página de smartmontools. Si puedes formatear, si puedes corregirlo, si no te vuelve a aparecer ningún otro mensaje de fallo, y si en definitiva, la decisión de si hacerlo o no depende únicamente de ti (porque es tu equipo, no de la empresa, por ejemplo) pues adelante, el riesgo, en este caso, es menor.
Para eso se hacen las copias de seguridad. Te puede fallar un disco de golpe aunque no te avise de nada.
Sabes que eso no siempre es posible o no siempre se hace "al día". Y las copias de seguridad no te evitan la pérdida de tiempo en volver a configurar el equipo al completo (parches, programas...). Ni te evitan que en medio de una presentación corporativa te casque el disco o se quede colgado leyendo el sector defectuoso.
Ya hemos hablado de la copia de seguridad.
Eso es independiente.
Pues cuando aumentan. Haces un chequeo, tienes uno. Haces otro, tienes tres. Haces otro, tienes seis...
¿Y 7, 15... y 20? ¿Cuándo lo cambias?
Este párrafo es muy interesante y confirma lo que digo:
(...) Sí, es bien interesante. Habla de discos scsi, habla de un proceso de reasignación de bloques donde se pueden perder datos y habla de que los autores no saben -no conocen- ningún ejemplo de comando para que bien el sistema operativo o el sistema de archivos lo lleve a cabo. ¿Que se puede "parchear" el disco? Claro. ¿Que conviene hacerlo y cuándo conviene hacerlo? Hum, pues de eso no dice nada >:-). Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-21 a las 19:42 +0100, Camaleón escribió:
El 21/03/08, Carlos E. R. escribió:
En el año 62, en que las memorias eran unos nucleos de ferrita diminutos con unos hilos de cobre que se pasaban a mano por unas hilanderas del sureste asiatico o de Filipinas muy hacendosas, y probablemente muy jovencitas (por las manos pequeñas y la buena vista), y dado que una placa de 1 kilobyte costaba una pasta, el año se ponía con dos cifras, y gracias.
Que en los años 90 el windows usara dos digitos, eso tiene delito.
Más que una limitación por los componentes, el error fue pensar "que no tendría ningún efecto secundario y que no pasaría nada...". Una mentalidad "ahorrativa" puede ser catastrófica.
No era ningún error. No había memoria suficiente para poner los años completos. Por esa misma razón se hacían los cálculos con bytes, o con menos todavía, si era posible. No había memoria, y se estrujaba al mínimo. Intenta programar un simulador de vuelo en una calculadora programable de 300 instrucciones y hablamos >:-) El error fué seguir usando ese mismo código cuando ya no había ese problema de limitación de memoria. En postponer el problema, que ya se veía venir, para los que vinieran después.
Pero no tiene mayor importancia, la historia está llena de cálculos erróneos que han conllevado desde batallas perdidas hasta millones perdidos. Son decisiones que hay que tomar y donde no siempre se acierta :-).
Sí.
Si un ingeniero hace un puente colgante con un millon de fibras, y el ordenador de control le dice que se ha roto una, simplemente toma nota y reduce la carga máxima en una millonésima.
Dependerá de la importancia que tenga sobre el conjunto "esa fibra". La decisión se basará en si puede degenerar en la rotura de otras fibras u otros elementos de la estructura. Se llama "indeterminación".
Está previsto en el diseño del cordaje que se rompan unas cuantas fibras.
Para eso se hacen las copias de seguridad. Te puede fallar un disco de golpe aunque no te avise de nada.
Sabes que eso no siempre es posible o no siempre se hace "al día". Y las copias de seguridad no te evitan la pérdida de tiempo en volver a configurar el equipo al completo (parches, programas...). Ni te evitan que en medio de una presentación corporativa te casque el disco o se quede colgado leyendo el sector defectuoso.
Se te puede quedar colgado aunque no tengas ningún sector defectuoso. Puede elegir ese preciso instante para cascar del todo, estando en estado de perfección. Y la perdida de tiempo la tendrás seguro si reemplazas el disco no habiendo necesidad demostrada.
Ya hemos hablado de la copia de seguridad.
Eso es independiente.
No, no lo es... el hardware es falible, lo puede hacer en cualquier instante, aunque todas las pruebas digan que está perfecto, y no halla fallado nunca antes. Debes estar preparado para el momento que falle, que fallará. De hecho, yo me fio más de un disco con 5000 horas que de uno con 50. Por cierto... el linux no se queda frito simplemente por encontrar un error en el disco. Te lo digo porque yo tengo un pc con docenas de errores activos en el disco.
Pues cuando aumentan. Haces un chequeo, tienes uno. Haces otro, tienes tres. Haces otro, tienes seis...
¿Y 7, 15... y 20? ¿Cuándo lo cambias?
Ya lo he dicho. En esos puntos suspensivos yo ya he cambiado el disco.
Este párrafo es muy interesante y confirma lo que digo:
(...)
Sí, es bien interesante. Habla de discos scsi, habla de un proceso de reasignación de bloques donde se pueden perder datos y habla de que los autores no saben -no conocen- ningún ejemplo de comando para que bien el sistema operativo o el sistema de archivos lo lleve a cabo.
¿Que se puede "parchear" el disco? Claro. ¿Que conviene hacerlo y cuándo conviene hacerlo? Hum, pues de eso no dice nada >:-).
En ese sitio no. Tampoco dicen que no se deba hacer. En otros sitios detallan el procedimiento para hacerlo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH5Ab/tTMYHG2NR9URAsLYAJ9wZWXC9kwZGYnQlhjhW816ASyLewCfWFUx x43Fy7ukhFryLTsxqTiptVU= =HybB -----END PGP SIGNATURE-----
El 21/03/08, Carlos E. R. escribió:
No era ningún error. No había memoria suficiente para poner los años completos. Por esa misma razón se hacían los cálculos con bytes, o con menos todavía, si era posible. No había memoria, y se estrujaba al mínimo.
Era un recurso escaso (eh, como hoy :-P) pero no había limitación de hardware "per se" (una buena -he dicho "buena"- gestión de la memoria siempre es deseable). El "error" fue sólo una decisión de los programadores en un intento de "gestionar" un recurso de una forma "ineficiente" e "incorrecta".
Intenta programar un simulador de vuelo en una calculadora programable de 300 instrucciones y hablamos >:-)
Siempre he pensando que los mejores juegos son los los que caben en un disquete... los otros (los que te piden tener casi un estudio de cine metido en el ordenador) ya son "películas" en tiempo real :-) Eh, que si hay que ahorrar, se ahorra... pero quitando de donde hay que quitar.
El error fué seguir usando ese mismo código cuando ya no había ese problema de limitación de memoria. En postponer el problema, que ya se veía venir, para los que vinieran después.
Mala gestión original --> mala gestión posterior
Está previsto en el diseño del cordaje que se rompan unas cuantas fibras.
No siempre. No en todas las situaciones. No con todos los materiales. No en distintos terrenos. No en todos los entornos (el comportamiento de una estructura varía en función de "elementos externos" como terremotos, huracanes, suelos arcillosos que propician el desprendimiento, etc...). Mismos componentes ante situaciones diferentes generan comportamientos diferentes.
Se te puede quedar colgado aunque no tengas ningún sector defectuoso. Puede elegir ese preciso instante para cascar del todo, estando en estado de perfección.
Y la perdida de tiempo la tendrás seguro si reemplazas el disco no habiendo necesidad demostrada.
Pero si no te avisa, la culpa no es tuya. El problema es ignorar de forma deliberada un mensaje de fallo.
No, no lo es... el hardware es falible, lo puede hacer en cualquier instante, aunque todas las pruebas digan que está perfecto, y no halla fallado nunca antes. Debes estar preparado para el momento que falle, que fallará.
Claro, pero no está en tu mano actuar antes de tiempo. Puedes ir cambiando las piezas que sabes son más susceptibles al error por el desgaste (ventiladores por ejemplo o fuente de alimentación o el disco duro) para evitar que llegue a "romperse" en un momento poco "oportuno" (aka, mantenimiento preventivo).
De hecho, yo me fio más de un disco con 5000 horas que de uno con 50.
Por eso hay que hacer el "rodaje" a los equipos que vas a poner en producción. ¿Tiempo? Yo los llego a tener meses en funcionamiento antes de pasarlos "al trabajo" diario... ... si te falla un disco duro que lleva 5000 horas de trabajo, culpa tuya por no cambiarlo a tiempo. ... si te falla el disco duro que lleva 50 horas, culpa del fabricante que no ha realizado los controles de calidad pertinentes. Choose your poison >:-)
Por cierto... el linux no se queda frito simplemente por encontrar un error en el disco. Te lo digo porque yo tengo un pc con docenas de errores activos en el disco.
Habrás tenido suerte. Busca las experiencias de otros usuarios con ese mismo error, con sectores defectuosos sin corregir y corregidos...
Ya lo he dicho. En esos puntos suspensivos yo ya he cambiado el disco.
¿6? ¿Y por qué 6? >:-) Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-21 a las 20:50 +0100, Camaleón escribió:
El 21/03/08, Carlos E. R. escribió:
No era ningún error. No había memoria suficiente para poner los años completos. Por esa misma razón se hacían los cálculos con bytes, o con menos todavía, si era posible. No había memoria, y se estrujaba al mínimo.
Era un recurso escaso (eh, como hoy :-P) pero no había limitación de hardware "per se" (una buena -he dicho "buena"- gestión de la memoria siempre es deseable).
Sí había limitación de hardware. Unos cuanto kb era lo máximo que podían poner, y tenías que ser de la CIA o la NASA para conseguirlos. Tú no has visto las placas de memoria de ferrita, tamaño A3 para un cuarto de kilobyte.
El "error" fue sólo una decisión de los programadores en un intento de "gestionar" un recurso de una forma "ineficiente" e "incorrecta".
Al contrario, era una decisión lógica de uso eficiente de los materiales existentes.
Intenta programar un simulador de vuelo en una calculadora programable de 300 instrucciones y hablamos >:-)
Siempre he pensando que los mejores juegos son los los que caben en un disquete... los otros (los que te piden tener casi un estudio de cine metido en el ordenador) ya son "películas" en tiempo real :-)
Se derivan de los medios disponibles en cada época.
Eh, que si hay que ahorrar, se ahorra... pero quitando de donde hay que quitar.
Pues eso, se quita del siglo, que este ordenador no va a durar tanto.
El error fué seguir usando ese mismo código cuando ya no había ese problema de limitación de memoria. En postponer el problema, que ya se veía venir, para los que vinieran después.
Mala gestión original --> mala gestión posterior
No, la gestión original era correcta para los recursos que tenían.
Está previsto en el diseño del cordaje que se rompan unas cuantas fibras.
No siempre. No en todas las situaciones. No con todos los materiales. No en distintos terrenos. No en todos los entornos (el comportamiento de una estructura varía en función de "elementos externos" como terremotos, huracanes, suelos arcillosos que propician el desprendimiento, etc...).
Mismos componentes ante situaciones diferentes generan comportamientos diferentes.
En el caso de los discos duros el fallo de los sectores está previsto. Hay por ahí una probabilidad estadística que te da la tasa de sectores fallados por cuestiones como simple ruido estadístico.
Se te puede quedar colgado aunque no tengas ningún sector defectuoso. Puede elegir ese preciso instante para cascar del todo, estando en estado de perfección.
Y la perdida de tiempo la tendrás seguro si reemplazas el disco no habiendo necesidad demostrada.
Pero si no te avisa, la culpa no es tuya. El problema es ignorar de forma deliberada un mensaje de fallo.
No se ignora.
No, no lo es... el hardware es falible, lo puede hacer en cualquier instante, aunque todas las pruebas digan que está perfecto, y no halla fallado nunca antes. Debes estar preparado para el momento que falle, que fallará.
Claro, pero no está en tu mano actuar antes de tiempo. Puedes ir cambiando las piezas que sabes son más susceptibles al error por el desgaste (ventiladores por ejemplo o fuente de alimentación o el disco duro) para evitar que llegue a "romperse" en un momento poco "oportuno" (aka, mantenimiento preventivo).
No, no puedes. Se intenta nada más.
De hecho, yo me fio más de un disco con 5000 horas que de uno con 50.
Por eso hay que hacer el "rodaje" a los equipos que vas a poner en producción. ¿Tiempo? Yo los llego a tener meses en funcionamiento antes de pasarlos "al trabajo" diario...
... si te falla un disco duro que lleva 5000 horas de trabajo, culpa tuya por no cambiarlo a tiempo.
Que va, 5000 horas es plena juventud :-p
... si te falla el disco duro que lleva 50 horas, culpa del fabricante que no ha realizado los controles de calidad pertinentes.
Depende de lo que hayas pagado; pero es lo habitual.
Choose your poison >:-)
Por cierto... el linux no se queda frito simplemente por encontrar un error en el disco. Te lo digo porque yo tengo un pc con docenas de errores activos en el disco.
Habrás tenido suerte. Busca las experiencias de otros usuarios con ese mismo error, con sectores defectuosos sin corregir y corregidos...
No, no es suerte. Sólo se cuelga cuando el sector en cuestión contiene un fichero imprescindible. Tiene que darse una serie de circunstancias para producir el cuelgue, no basta con tener un error de lectura.
Ya lo he dicho. En esos puntos suspensivos yo ya he cambiado el disco.
¿6? ¿Y por qué 6? >:-)
Porque en cada prueba aumenta >:-) Un error fortuito es una cosa. Un error que va aumentando es otra muy distinta. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH5CAetTMYHG2NR9URAglcAJ9kbToBOBQakIMz8OaabWSu/agOVwCgmYd8 HTh1mSdB+4H876g9IlHt4t4= =DyeM -----END PGP SIGNATURE-----
El 21/03/08, Carlos E. R. escribió:
Sí había limitación de hardware. Unos cuanto kb era lo máximo que podían poner, y tenías que ser de la CIA o la NASA para conseguirlos.
Tú no has visto las placas de memoria de ferrita, tamaño A3 para un cuarto de kilobyte.
Hay que aprovechar al máximo los recursos disponibles. La memoria era escasa pero no inexistente. Y hay, lo que llama, "prioridades". Ese error fue, claramente, un error "humano", falta de visión o "mente de programador" (centrada en un objetivo) que les llevó a valorar de una forma errónea el significado real de lo que estaban haciendo. Mira, la wiki lo explica perfectamente en el artículo del Y2K: *** http://en.wikipedia.org/wiki/Y2k "(...) the first person known to publicly address the problem was Bob Bemer who had noticed it in 1958, as a result of work on genealogical software. He spent the next twenty years trying to make programmers, IBM, the US government and the ISO aware of the problem, with little result. This included the recommendation that the COBOL PICTURE clause should be used to specify four digit years for dates. This could have been done by programmers at any time from the initial release of the first COBOL compiler in 1961 onwards. However, lack of foresight, the desire to save storage space, and overall complacency prevented this advice from being followed." *** Pobre Bob... intentando explicar a los programadores ¡que estaban equivocados! :-) "Falta de visión, deseo de ahorrar espacio..." Hum, qué raro, no dice nada de "memoria físicamente no disponible" >:-)
Al contrario, era una decisión lógica de uso eficiente de los materiales existentes.
Una decisión lógica, no, yo diría más bien "arbitraria", donde no se valoró más que una variable: la memoria. Ese fue el gran error.
Pues eso, se quita del siglo, que este ordenador no va a durar tanto.
Premisas, todas ellas, que el tiempo ha demostrado que eran incorrectas. Hay que ser (o intentar ser) "globales" -y no sólo en informática-, hay que prever no el "hoy" ni el "ahora", sino ir más allá del momento actual porque no sabes qué puede pasar ni cómo se van a desarrollar las cosas: esa es la belleza del orden... y del caos. "El aleteo de una mariposa en Hong Kong puede desatar una tormenta en Nueva York..." Creo que la informática en general debería desarrollar un pensamiento más científico para poder interactuar de una forma más precisa con el entorno que la rodea... sería más efectiva... sería casi, perfecta.
No, la gestión original era correcta para los recursos que tenían.
Según esa teoría, nunca existiría el error :-): siempre se trabaja en base a lo que se conoce, eso es obvio, pero disponer de datos "limitados" no te exime -ni justifica- el fracaso. Hay que "saber (o aprender a) prever".
En el caso de los discos duros el fallo de los sectores está previsto. Hay por ahí una probabilidad estadística que te da la tasa de sectores fallados por cuestiones como simple ruido estadístico.
¿Y no hay por ahí alguna directriz que indique qué hacer en caso de fallo? >:-)
No se ignora.
No, bueno... lo parcheas :-) Pero ¿cómo evaluas la efectividad del parche?
No, no es suerte. Sólo se cuelga cuando el sector en cuestión contiene un fichero imprescindible. Tiene que darse una serie de circunstancias para producir el cuelgue, no basta con tener un error de lectura.
Todo eso que acabas de decir, es, precisamente, lo que se considera como "suerte": suerte. (Del lat. sors, sortis). Encadenamiento de los sucesos, considerado como fortuito o casual :-P
Porque en cada prueba aumenta >:-)
Un error fortuito es una cosa. Un error que va aumentando es otra muy distinta.
También aumenta de 1 a 2, o de 2 a 5... ¿En qué dato científico, lógico, comparable y reproducible basas, pues, tu decisión de que el 6 es "la hora de cambiar de disco"? >:-) Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-03-22 a las 00:35 +0100, Camaleón escribió:
El 21/03/08, Carlos E. R. escribió:
Sí había limitación de hardware. Unos cuanto kb era lo máximo que podían poner, y tenías que ser de la CIA o la NASA para conseguirlos.
Tú no has visto las placas de memoria de ferrita, tamaño A3 para un cuarto de kilobyte.
Hay que aprovechar al máximo los recursos disponibles. La memoria era escasa pero no inexistente. Y hay, lo que llama, "prioridades".
Ese error fue, claramente, un error "humano", falta de visión o "mente de programador" (centrada en un objetivo) que les llevó a valorar de una forma errónea el significado real de lo que estaban haciendo.
Mira, la wiki lo explica perfectamente en el artículo del Y2K:
*** http://en.wikipedia.org/wiki/Y2k
"(...) the first person known to publicly address the problem was Bob Bemer who had noticed it in 1958, as a result of work on genealogical software. He spent the next twenty years trying to make programmers, IBM, the US government and the ISO aware of the problem, with little result. This included the recommendation that the COBOL PICTURE clause should be used to specify four digit years for dates. This could have been done by programmers at any time from the initial release of the first COBOL compiler in 1961 onwards. However, lack of foresight, the desire to save storage space, and overall complacency prevented this advice from being followed." ***
Pobre Bob... intentando explicar a los programadores ¡que estaban equivocados! :-)
"Falta de visión, deseo de ahorrar espacio..." Hum, qué raro, no dice nada de "memoria físicamente no disponible" >:-)
Yo he tenido que regatear byte a byte el código de programas para que cupieran en la memoria que tenía disponible. No sólo quitas el siglo de los años, quitas los decenios y lo que haga falta. Si tienes que medir alturas de 100 metros, pones un shortint cuyo máximo es 127. Es una labor de encaje de bolillos, de Ingeniería con mayúsculas, de aplicar el ingenio para conseguir resultados con los míseros medios disponibles. Los programadores iniciales no erraron en absoluto. La metedura de pata fué de los que vinieron después, que no se molestaron en rehacer los códigos que estaban diseñados para una época de escasez de recursos. Oye, que hasta los impresos te ponían el 19__.
Al contrario, era una decisión lógica de uso eficiente de los materiales existentes.
Una decisión lógica, no, yo diría más bien "arbitraria", donde no se valoró más que una variable: la memoria. Ese fue el gran error.
Una variable _fija_, que no estaba en su mano aumentar. No fué un error.
Pues eso, se quita del siglo, que este ordenador no va a durar tanto.
Premisas, todas ellas, que el tiempo ha demostrado que eran incorrectas. Hay que ser (o intentar ser) "globales" -y no sólo en informática-, hay que prever no el "hoy" ni el "ahora", sino ir más allá del momento actual porque no sabes qué puede pasar ni cómo se van a desarrollar las cosas: esa es la belleza del orden... y del caos.
Eso lo tenían que hacer los que decidieron reusar código antiguo. Los que ahorraron tiempo y sueldo de programadores en no modernizar las cosas.
"El aleteo de una mariposa en Hong Kong puede desatar una tormenta en Nueva York..."
Eso es una tergiversación de la teoría del caos, a la que se agarran los periodistas.
Creo que la informática en general debería desarrollar un pensamiento más científico para poder interactuar de una forma más precisa con el entorno que la rodea... sería más efectiva... sería casi, perfecta.
Sí. Ahora. No los pioneros.
No, la gestión original era correcta para los recursos que tenían.
Según esa teoría, nunca existiría el error :-): siempre se trabaja en base a lo que se conoce, eso es obvio, pero disponer de datos "limitados" no te exime -ni justifica- el fracaso. Hay que "saber (o aprender a) prever".
Mira, eso es como diseñar un puente para 20 toneladas y 15 años de uso, y luego pretender seguir usandolo 5 años más y con trailers de veinte ruedas. Las cosas se diseñan con unas premisas, unos materiales, unos costos, unas limitaciones, y unos resultados. El ingeniero trabaja con lo que le dan. Quejarse de que lo que hace no es eterno es absurdo. No se diseñó para eso. El error es o de los politicos que inicialmente no presupuestaron un puente más capaz, o de los políticos posteriores que no presupuestaron su substituto a tiempo. Pero no del ingeniero, que cumplió perfectamente con lo que le pideron.
En el caso de los discos duros el fallo de los sectores está previsto. Hay por ahí una probabilidad estadística que te da la tasa de sectores fallados por cuestiones como simple ruido estadístico.
¿Y no hay por ahí alguna directriz que indique qué hacer en caso de fallo? >:-)
Claro que las hay. Pero no toda la documentación es abierta y conocida.
No se ignora.
No, bueno... lo parcheas :-) Pero ¿cómo evaluas la efectividad del parche?
¿Y como evaluas la efectividad de los sectores que un disco que no ha fallado nunca? No puedes. Simplemente ese disco ha caido del lado afortunaco de la estadística. Los campos magnéticos que se graban en los discos modernos son ridículamente debiles. Están en el margen de lo indetectable: que se puedan leer es casi un milagro. Hay una tasa de error estadístico que te dice que las lecturas del disco van a fallar varios miles o millones de veces, y lo puedes medir: 9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 5136 195 Hardware_ECC_Recovered 0x001a 060 047 000 Old_age Always - 188948838 Ese disco (320.0 GB) ha tenido 188.948.838 fallos. ¡Unos 188 millones de fallos! Pero son errores que el hardware ha conseguido recuperar, es decir, corregir el fallo a base de bytes redundantes del propio sector. Es normal que en todos esos millones de fallos de vez en cuando se produzca uno algo mayor que afecte a demasiados bytes, de tal forma que la redundancia prevista sea incapaz de corregirlo: ya tienes un error "incorregible" de manera automática. El disco reporta un error y deja al sistema operativo o al usuario que decida como corregirlo. Otro disco más antiguo (40.0 GB): 9 Power_On_Hours 0x0032 076 076 000 Old_age Always - 21285 195 Hardware_ECC_Recovered 0x001a 100 253 000 Old_age Always - 0 no ha tenido ni un solo error de esos, porque usaba una tecnología menos compacta y más fiable.
No, no es suerte. Sólo se cuelga cuando el sector en cuestión contiene un fichero imprescindible. Tiene que darse una serie de circunstancias para producir el cuelgue, no basta con tener un error de lectura.
Todo eso que acabas de decir, es, precisamente, lo que se considera como "suerte":
suerte. (Del lat. sors, sortis). Encadenamiento de los sucesos, considerado como fortuito o casual
:-P
Pos llámalo como quieras... los puentes no se caen por suerte. No se, yo no me acerco a los rascacielos. Puede caerse una piedrecita o un tornillo de los cristales por mala suerte y romperme la crisma.
Porque en cada prueba aumenta >:-)
Un error fortuito es una cosa. Un error que va aumentando es otra muy distinta.
También aumenta de 1 a 2, o de 2 a 5... ¿En qué dato científico, lógico, comparable y reproducible basas, pues, tu decisión de que el 6 es "la hora de cambiar de disco"? >:-)
No me decide el 2 ni el 6 ni el 10 ni el 50. Me decide el hecho de que aumenta en cada prueba. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH5XIxtTMYHG2NR9URAg5iAJ4zoxLTJn7/lg0Yg84mougRkxU9uwCggqq7 oSlRK0Tudzw7V6UQ+WUYFbo= =EA9P -----END PGP SIGNATURE-----
El 22/03/08, Carlos E. R. escribió:
Yo he tenido que regatear byte a byte el código de programas para que cupieran en la memoria que tenía disponible. No sólo quitas el siglo de los años, quitas los decenios y lo que haga falta. Si tienes que medir alturas de 100 metros, pones un shortint cuyo máximo es 127. Es una labor de encaje de bolillos, de Ingeniería con mayúsculas, de aplicar el ingenio para conseguir resultados con los míseros medios disponibles.
Pero no se puede extrapolar a todas las situaciones a un caso particular, eso no es ser objetivo :-). Nadie dice que la gestión eficiente de la memoria sea una tarea sencilla (ni antes ni ahora), pero tampoco imposible. Y si tienes que "ahorrar" memoria o espacio, ¿no hubiera sido mejor sacarla de otro sitio? Hasta hoy día la fecha nos trae de cabeza en los equipos modernos: el ordenador necesita saber en qué tiempo vive (lamentablemente aún hoy no lo puede calcular de forma automática, todo llegará... :-P) pero es una de las primeras cosas que tienes que configurar cuando instalas un sistema operativo, fecha y hora... ... y es una de las pocas cosas de las que tienes que preocuparte que esté correctamente configurada... o se te puede ir todo al garete (servidores web, programas, cálculos...). La fecha, en un sistema informático, es casi tan importante como la memoria o el disco duro: entrada de datos incorrectos --> procesamiento erróneo --> resultado de salida falso No es una variable "susceptible de recorte" para ahorrar.
Los programadores iniciales no erraron en absoluto. La metedura de pata fué de los que vinieron después, que no se molestaron en rehacer los códigos que estaban diseñados para una época de escasez de recursos.
Oye, que hasta los impresos te ponían el 19__.
La metedura de pata fue de todos ellos; unos por no valorar correctamente de dónde sacar más espacio o más memoria y los otros por infravalorarlo (o ignorarlo) cuando ya no suponía un problema físico...
Una variable _fija_, que no estaba en su mano aumentar. No fué un error.
Oh, claro que estaba en su mano: era su elección, podían haber ahorrado de cualquier otra forma, siempre hay alternativas. Y obviamente, esa elección fue un error.
Eso lo tenían que hacer los que decidieron reusar código antiguo. Los que ahorraron tiempo y sueldo de programadores en no modernizar las cosas.
"Tiempo y sueldo" no deben interferir en la calidad de un programa. Ahora, año 2008, sí. Antes, años 1960, no. La informática estaba sólo al alcance de unos pocos, grandes empresas o gobiernos y los programas cumplían funciones específicas: desde el control de centrales eléctricas hasta el cálculos de estructuras. Mientras que los los programadores actuales suelen tener menos de 25 años, los de antes no tenían menos de 40... quiero decir con ésto que el "lo quiero para mañana y si no está documentado, mejor" dudo que se diera en aquélla época (y dudo que se también ahora en sectores industriales críticos que dependen casi por completo de los ordenadores).
Eso es una tergiversación de la teoría del caos, a la que se agarran los periodistas.
¿"Tergiversación"? Ninguna. No es más que un ejemplo gráfico que intenta resumir una teoría compleja. Que la relación "causa-efecto" es difícil de calcular y que no siempre el derrotero de las cosas sigue el cauce establecido...
Sí. Ahora. No los pioneros.
No, antes y ahora. Es más, antes "era más científica". La mayoría de los programadores tenían conocimientos sólidos de matemáticas, biología o física. Eran matemáticos, biólogos o físicos :-). La informática no era más que un medio para demostrar una teoría o para agilizar los procesos manuales. Ahora, esa esencia original se ha perdido, la informática es el "fin", no el "medio". Los informáticos (y todas las disciplinas, en general) se han especializado tanto que nos hemos vuelto "uni-disciplinares" y sólo unos pocos individuos (muy pocos) son capaces de desarrollar una visión "multi-disciplinar", casi "renacentista" de las cosas, es decir, ser capaces de una abstracción tal que les permita saber (prever) la mayor parte de las situaciones y procesos.
Mira, eso es como diseñar un puente para 20 toneladas y 15 años de uso, y luego pretender seguir usandolo 5 años más y con trailers de veinte ruedas. Las cosas se diseñan con unas premisas, unos materiales, unos costos, unas limitaciones, y unos resultados. El ingeniero trabaja con lo que le dan. Quejarse de que lo que hace no es eterno es absurdo. No se diseñó para eso.
Me quejo, me quejo... y me quejo porque el puente tiene fecha de caducidad, lo pone en el contrato, firmado por el ingeniero y el arquitecto: "este puente de características x tiene una esperanza de vida de n años". ¿Y qué sucede con el programa? ¿Dónde pone la fecha de caducidad? No la tiene y por lo tanto, queda al azar si su funcionamiento se convierte en errático cuando pasen "x" años... y queda al azar proque nadie se ha responsabilizado de ello.
El error es o de los politicos que inicialmente no presupuestaron un puente más capaz, o de los políticos posteriores que no presupuestaron su substituto a tiempo. Pero no del ingeniero, que cumplió perfectamente con lo que le pideron.
Como excusa está bien :-). Pero eso no es así. Está claro que quien construye el puente (peones de obra) no tienen culpa de nada, no es su trabajo ni su responsabilidad. Para eso está en "autor conceptual" del trabajo: el arquitecto (o ingeniero). Este no "pica", piensa, desarrolla y planifica. No "pica", pero se responsabiliza de su obra al 100%.
Claro que las hay.
Pero no toda la documentación es abierta y conocida.
No la hay, no se puede predecir con exactitud el fallo de un componente, por eso precisamente están los pre-avisos y las alertas.
¿Y como evaluas la efectividad de los sectores que un disco que no ha fallado nunca? No puedes. Simplemente ese disco ha caido del lado afortunaco de la estadística.
Los campos magnéticos que se graban en los discos modernos son ridículamente debiles. Están en el margen de lo indetectable: que se puedan leer es casi un milagro. Hay una tasa de error estadístico que te dice que las lecturas del disco van a fallar varios miles o millones de veces, y lo puedes medir:
9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 5136 195 Hardware_ECC_Recovered 0x001a 060 047 000 Old_age Always - 188948838
De esas dos variables no hemos estado hablando en este hilo. Las horas de funcionamiento no es un valor que se pueda "reparar" como un sector defectuoso. El otro valor indica las recuperaciones automáticas que ha llevado a cabo el disco de forma transparente ¿no? pues es lo que debe hacer... cuando no puede hacerlo el disco, aparece el otro error, que requiere la intervención del usuario.
Ese disco (320.0 GB) ha tenido 188.948.838 fallos. ¡Unos 188 millones de fallos! Pero son errores que el hardware ha conseguido recuperar, es decir, corregir el fallo a base de bytes redundantes del propio sector. Es normal que en todos esos millones de fallos de vez en cuando se produzca uno algo mayor que afecte a demasiados bytes, de tal forma que la redundancia prevista sea incapaz de corregirlo: ya tienes un error "incorregible" de manera automática. El disco reporta un error y deja al sistema operativo o al usuario que decida como corregirlo.
Otro disco más antiguo (40.0 GB):
9 Power_On_Hours 0x0032 076 076 000 Old_age Always - 21285 195 Hardware_ECC_Recovered 0x001a 100 253 000 Old_age Always - 0
no ha tenido ni un solo error de esos, porque usaba una tecnología menos compacta y más fiable.
La antigüedad no es un factor "per se" de fallo. En este caso, creo que es más importante el hecho de que sea un disco duro que está en un equipo portátil (susceptible a golpes o a un calentamiento elevado) que las horas de uso.
Pos llámalo como quieras... los puentes no se caen por suerte.
Huy, sí... el "factor azar" también hay que tenerlo en cuenta. Suele ser además, "factor determinante"... ¿es que no conoces las leyes de murphy? ;-)
No me decide el 2 ni el 6 ni el 10 ni el 50. Me decide el hecho de que aumenta en cada prueba.
Pero no es un valor fijo... es una apreciación tuya, personal, que puede ser correcta, o no. A eso voy. Ya tenemos bastante "indeterminación" en esta vida como para tener que estar adivinando si el aumento "de 1 a 5" o de "5 a 7" supone un factor o no de riesgo :-P. Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (4)
-
Camaleón
-
Carlos E. R.
-
Cristian Rodríguez
-
Josep m Solé