Bonsoir,
je regarde sur mes debians ce soir.
Mais juste une question. Est on certain que le parkage des têtes est dommageable ?
questionnaire en cours sur GD
generation-debian.org/forums … 3271#p3270
serais bien de faire de même ici , pour y voir plus clair dans cette histoire , dans le but de transmettre des choses concrètes au devs debian concernant ce problème!
merci 
Question pertinente. Je pense, mais ça reste mon avis personnel, que quelques cycles de parquage ne font rien de mal, mais à la longue ça doit user les têtes et la zone de parquage pour finalement rendre le disque-dur inopérant. Mais cela ne reste que mon avis.
[quote=“mattotop”]quote="debianhadic"
Pour en revenir aux problèmes des disques dur, vous me confirmez que de toute façon ça ne s’applique qu’aux portables ?[/quote]Bah ça doit dépendre aussi comment on a configuré son desktop.
Sinon, une fois compris le truc, autant vérifier toutes les machines.
Mais j’ai toujours pas compris comment on détectait le réglage foireux.[/quote]
La question de debianhadic m’interesse aussi, parce que je n’est qu’un desktop. De mon côté, je suis sous Dapper, j’ai effectué quelques test dont voici les retour (je trouve d’ailleurs certains valeurs suspectent):
[code]$ sudo smartctl -a /dev/hda
smartctl version 5.34 [i686-pc-linux-gnu] Copyright © 2002-5 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Device Model: Maxtor 6L080L0
Serial Number: L25W608G
Firmware Version: BAJ41G20
User Capacity: 81�964�302�336 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 0
Local Time is: Tue Oct 30 15:24:42 2007 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
[…]
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
3 Spin_Up_Time 0x0027 227 226 063 Pre-fail Always - 6041
4 Start_Stop_Count 0x0032 253 253 000 Old_age Always - 805
5 Reallocated_Sector_Ct 0x0033 253 253 063 Pre-fail Always - 0
6 Read_Channel_Margin 0x0001 253 253 100 Pre-fail Offline - 0
7 Seek_Error_Rate 0x000a 253 251 000 Old_age Always - 0
8 Seek_Time_Performance 0x0027 243 237 187 Pre-fail Always - 51566
9 Power_On_Hours 0x0032 247 247 000 Old_age Always - 63665
10 Spin_Retry_Count 0x002b 253 252 157 Pre-fail Always - 0
11 Calibration_Retry_Count 0x002b 253 252 223 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 251 251 000 Old_age Always - 827
192 Power-Off_Retract_Count 0x0032 253 253 000 Old_age Always - 0
193 Load_Cycle_Count 0x0032 253 253 000 Old_age Always - 0
194 Temperature_Celsius 0x0032 040 253 000 Old_age Always - 42
195 Hardware_ECC_Recovered 0x000a 253 252 000 Old_age Always - 4631
196 Reallocated_Event_Count 0x0008 253 253 000 Old_age Offline - 0
197 Current_Pending_Sector 0x0008 253 253 000 Old_age Offline - 0
198 Offline_Uncorrectable 0x0008 253 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0008 199 199 000 Old_age Offline - 0
200 Multi_Zone_Error_Rate 0x000a 253 252 000 Old_age Always - 0
201 Soft_Read_Error_Rate 0x000a 253 252 000 Old_age Always - 0
202 TA_Increase_Count 0x000a 253 252 000 Old_age Always - 0
203 Run_Out_Cancel 0x000b 253 252 180 Pre-fail Always - 0
204 Shock_Count_Write_Opern 0x000a 253 252 000 Old_age Always - 0
205 Shock_Rate_Write_Opern 0x000a 253 252 000 Old_age Always - 0
207 Spin_High_Current 0x002a 253 252 000 Old_age Always - 0
208 Spin_Buzz 0x002a 253 252 000 Old_age Always - 0
209 Offline_Seek_Performnce 0x0024 241 241 000 Old_age Offline - 150
[/code]
J’ai fait le test avec mon autre hd slave (hdb), la c’est sensiblement la même chose (sauf que je n’est pas la ligne qui m’interesse, soit Local_Cycle_Count).
Je rejoins donc mattotop, ca doit venir de la config de la machine, les Desktop n’ayant pas de raison de gérer une batteries, ils sont moins touché par le problème, le disque avec Dapper ont tout deux 1 ans 1/2, pas le moindre claquement.
Maintenant, j’avour ne pas connaître tous les moyens de contrôles …
Mais j’ai vérifier dans /etc/default/acpi-support, et j’ai bien:
[code]# Switch to laptop-mode on battery power - off by default as it causes odd
hangs on some machines
ENABLE_LAPTOP_MODE=false[/code]
Salut les Debianuxiens!
Avec cette histoire, je n’ose plus allumer mon portable. Bon, en fait j’ai installé Léopard sur mon iMac et fait quelques recherches avant de revenir sur Debian et de voir mon disque dur exploser. Bon, j’ai trouvé ça:
[i]"I found out about this bug from Digg this morning. After investigating, I found that the load cycle on my harddrive was increasing rapidly, both on AC and on battery. This sounds like a fairly serious bug, and should be dealt with quickly. I’ve made the following changes, which seems to have fixed it (load cycle doesn’t increase on AC, and doesn’t seem to increase much on DC).
In /etc/laptop-mode/laptop-mode.conf:
CONTROL_HD_IDLE_TIMEOUT=1
LM_AC_HD_IDLE_TIMEOUT_SECONDS=300
LM_BATT_HD_IDLE_TIMEOUT_SECONDS=300
NOLM_HD_IDLE_TIMEOUT_SECONDS=7200
CONTROL_HD_POWERMGMT=1
BATT_HD_POWERMGMT=254
LM_AC_HD_POWERMGMT=255
NOLM_AC_HD_POWERMGMT=255
In /etc/default/acpi-support:
ENABLE_LAPTOP_MODE=true
SPINDOWN_TIME=60
In /etc/acpi/power.sh:
Changed “$HDPARM -B 1 /dev/$drive 2>/dev/null” to “$HDPARM -B 254 /dev/$drive 2>/dev/null”
To Blue:
$ sudo on_ac_power; echo $?
0
$ sudo ps axu | grep apm | grep -v grep
"[/i]
Et il me semble que cela fonctionne pour moi. La température est juste un peu plus élevée.
j’ai pas ses fichiers de conf sur ma debian
laurent@portable:~$ cat /etc/laptop-mode/laptop-mode.conf
cat: /etc/laptop-mode/laptop-mode.conf: Aucun fichier ou répertoire de ce type
laurent@portable:~$ cat /etc/default/acpi-support
cat: /etc/default/acpi-support: Aucun fichier ou répertoire de ce type
laurent@portable:~$ cat /etc/acpi/power.sh
cat: /etc/acpi/power.sh: Aucun fichier ou répertoire de ce type
laurent@portable:~$
soit
hdparm -B 254 /dev/hda
ou
hdparm -B 255 /dev/hda
soit
[i]The command hdparm -b 255 turn off completely APM.
Here is how I permanently fixed it:
- make a file named “99-hdd-spin-fix.sh”. The important thing is starting with “99”.
- make sure the file contains the following 2 lines (fix it if you have PATA HDD):
#!/bin/sh
hdparm -B 255 /dev/sda - copy this file to 3 locations: /etc/acpi/suspend.d/ /etc/acpi/resume.d/ /etc/acpi/start.d/
Voila! After that the HDD never spins down on power (looks like it actually spins down on battery at modest rate).[/i]
[i]I have an Dell Inspiron 6400 running Gentoo. I had this problem too. I fixed it by adding
# -B 255 doesn't work for me
sda_args="-B 254 -S 60"
to /etc/conf.d/hdparm. This would fix the issue on boot, but after resuming, this would be moot. For that, I added
# redo hdparm settings on resume /etc/init.d/hdparm restart
after running /etc/acpi/suspend.sh in /etc/acpi/default.sh, though I suppose I could have put that line somwhere in suspend.sh.
The key thing here is to run hdparm on boot and on resume[/i]
Il faut certainement que les machins acpi et laptop-mode soient installés. Mais chez moi cela fonctionne. Mon Inspiron 1501 est alumé depuis 4 Heures maintenant (Je charge Opensuse et j’ai eu une merde au milieu du chargement; Je vais la tester à la place d’Ubuntu et garder ma Debian sur laquelle je suis en ce moment). La température monte à 51° et ne semble pas aller plus haut. A suivre… Donc.
Je viens de me rendre compte que tu es sous 64. Ce ne sont peut-être pas les mêmes fichiers?
le desktop est en 64 bits , mais hélas le laptop est lui seulement en 32 , bon vais pas râler marche très bien pour une antiquité
sinon plus d’infos sur les packages installés
generation-debian.org/forums … ?f=8&t=350
C’est bizarre. Je n’arrive pas à fixer le Pb sous Ubuntu après avoir essayé un tas de solutions. Cela finit toujours par reprendre. Alors que la solution trouvée et que j’ai soumise plus haut fonctionne impécablement sous Debian. Bon, comme j’ai enfin réussi à charger un CD d’OpenSuse, je vais virer Ubuntu, augmenter la taille de ma parttition Debian et tester OpenSuse sur le reste.
Par contre le silence d’Ubuntu (Ou c’est presque tel) et de Debian sur le sujet est assommant , frustrant, et à rendre parano.
D’autres parts ce problème semble exister depuis belle lurette sous Ubuntu, Debian et autres dérivés (Ou non); alors je ne comprends pas trop pourquoi on lit une rafale de témoignages relatant de vertigineuses augmentations du Count-load_machin via Smart-truc et pas la même quantité (ou presque) de témoignages de pétages, d’explosions (choisir le terme) de disques durs.
Bonsoir
J’ ai un laptop sous freebsd 6.2 et il a a peu pres le meme probleme.
Environ deux load cycles a la minute et je n’ai pas hdparm.
Sur les forums bsd, ce probleme n’est pas evoque.
si vous voulez j’ai fais un script cron pour checker le nombre de cycles à interval de temps régulier (histoire d’éviter un sleep 3600 dans un while(1) question de principe 
) avec un petit script qui vous donne votre moyenne à l’heure .
tout est ici :
http://www.generation-debian.org/forums/viewtopic.php?f=24&t=368
Sans faire de prosélytisme; j’ai installé et rendu opérationnelle OpenSuse sur mon “laptop” et je peux vous confirmer (Je l’avais lu ailleurs) que le problème semble ne pas exister sur cet OS. Et ça sans aucun script ou paramétrage particulier.
Mais alors, quand on a l’habitude de Debian ou de Ubuntu, on rame. C’est “User friendly” jusqu’au moment où on ne veux pas de faire des trucs qui nécessite un terminal. Pour le WiFi, j’ai suivi un truc trouvé sur un Blog Ubuntu et concernant mon modèle de portable mais j’ai tâtonné avant d’y arriver. De plus le paquet si utile airport-utils qui permet de paramétrer une borne WiFi Apple n’existe pas comme sous Debian. Du coup j’ai découvert qu’on pouvait paramétrer sa borne pour qu’elle se connecte toute seule à Internet dès qu’une application en a besoin et se déconnecte après un temps préfixé: ce que je ne savais pas après des années d’utilisation. Au moins cela aura eu du bon. Vu que je peux faire le paramétrage à partir de mon iMac ou de Mon portable via Debian.
Bon Ok, c’est un peu hors sujet.
Bon, j’ai mis un peu de temps à réagir car je voulais savoir ce qu’il en était. Après des essais, ce pbm apparait dès qu’on utilise ext3 et qu’on installe un ACPI un tant soit peu efficace. Cela explique à mon avis que Suse (peu orienté portable car plus destiné machine de bureau) ne connait pas ce problème. Ce problème apparait sous Etch, Sarge, etc dès qu’on a un portable et une partition en ext3 avec une écriture régulière des journaux.
Ce problème n’existe pas sous un XP standard (Incrémentation de 5 à 6 en une heure)
Ce problème disparait effectivement dès qu’on règle l’APM du disque dur de manière un peu moins agressive via hdparm.
La valeur de 600000 semble être une garantie de certains constructeurs d’après ce que j’ai vu. Si le disque dur flanche, elle ne s’applique plus. Rien ne dit que ça soit dommageable mais les clics que cela produit sont quand même inquiétants.
Par valeur de 600 000, tu entends quoi fran.b? Le nombre de Load_Cycle_Counts ou bien le paramètre passé à hdparm (il est pas censé être entre 0 et 255 ce paramètre?)
Sinon penses-tu que le problème de la croissance rapide des load_cycle est embêtant car:
–> le fabricant a mis une valeur limite d’office pour ce paramètre dans le firmware du dd, valeur au delà de laquelle le dd ne fonctionnera plus même si il est fonctionnel.
–> le matériel risque de lâcher au bout d’un nombre trop important de load_cycle?
Concrètement est-ce une contrainte artificielle imposée ou alors est-ce que ça dégrade réellement le matériel?
Cette valeur de 600000 (nombre de LOAD_CYCLE), je l’ai vu dans plusieurs spécifications techniques de disques durs sur Internet. C’est une limitation commerciale car c’est un seuil au delà duquel la garantie constructeur s’arrête, par contre le disque dur continue à fonctionner au delà du seuil. Simplement, le disque est considéré comme vieux par le constructeur: Dans un équipement essentiel, sans doute prendrait-on la décision de remplacer le dit disque.
Quant à savoir l’impact réel, je ne sais pas trop, le bruit que cela occasionne est suffisamment inquiétant -et en tout cas énervant- pour modifier le paramétrage du disque via hdparm. C’est de toute façon un problème matériel réel.
Merci, c’est très clair. Il faut donc se renseigner sur nos disques. Aurais-tu une doc à conseiller sur l’usage de smartmontools?
Si le bug etait déjà dans sarge, c’est quand même étonnant que le problème n’est pas été corrigé ni même soulevé depuis 3 ans!!.
c’est pas si dramatique que sa,
il suffit de régler le hdparm en fonction de l’utilisation de la bécane et ya plus de soucis
Pour une distribution comme debian ce n'est pas gênant, pour d'autres qui convoitent un publique différent, je trouve que ça l'est mais c'est mon point de vue.
Ba justement, sa permet de préserver la vie du disque en cas de choc ! Je trouve pas ça si mal que ça moi