Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Disque dur qui s'emballe

[supprimé]

Salut à tous !

J'ai un petit problème de disque dur. Rien de bien méchant, mais C un peu lourd à la longue. Je m'explique :
Je lorsque je suis sous ma Fedora Core 2, au bout d'environ 30 min, le HDD s'emballe pour rien, comme si il faisait un scan du disque en fait et se calme 5 à 10 min plus tard. Mais bon, pendant ce temps, je peux aller prendre un café car rien ne répond.
Alors bon, je ne sais que penser car sur cet HDD, j'ai aussi une partition WinXP. Mais le problème ne survient que sous linux.

Quelqu'un aurait-il une idée, ou aurait-il déjà été confronté à ce problème.
Merci et bonne journée à vous

PS : Très utile la Faq de ce site ! C grace à vous que j'ai installé une Fedora ! Continuez ainsi ...

CassBeck

C'est peut-être un job automatisé,
du style updatedb (ça fait bien mouliner le disque ça)

il faut allez voir dans
/etc/cron.hourly
/etc/cron.daily
...
Et virer les scripts qui ne te conviennent pas.

sinon tu as aussi la commande cronttab -l (-l de mémoire)

fmatias

C'est anacron et c'est normal.
Tu dois éteindre ton PC la nuit (c'est bien 🙂) et lorsque tu bootes ton PC la journée, il fait les tâches prévues pour la nuit précédente et qui n'ont pas été faite. Typiquement updatedb.

Marcet

Je doute qu'un updatedb surtout lancé en tache de fond ralentisse le PC au point d'en empêcher l'utilisation. En plus, l'updatedb ne prends beaucoup de temps que la première fois.

Il doit y avoir autre chose. Mais pour en avoir le coeur net, il serait effectivement bon de désactiver anacron temporairement.

fmatias

> Je doute qu'un updatedb surtout lancé en tache de fond ralentisse le PC

Ça dépend ce que tu fais. Si tu demandes un truc qui exige beaucoup d'accès disque, ça ralenti plus que significativement.

L'autre "problème" est que updatedb crée beaucoup de "cache" au niveau noyau. Du cache qui a viré le cache utile aux autres applis. Donc lorsque tu lances une nouvelle appli ou utilise à nouveau une applie qui était "endormie" durant le "updatedb", c'est lent.

Fais le test.
Lances "free" pour connaitre l'état de la mémoire.
Lances "find / > /dev/null 2>&1"
Lances "free" à nouveau et fais un diff (buffer a augmenté).

Il n'y a pas de solution à ce "faux" problème. C'est génant pour les petites configs (<= 256Mo).

> En plus, l'updatedb ne prends beaucoup de temps que la première fois.

Non.
Fais le test 🙂
Vires /var/lib/slocate/slocate.db pour faire croire que c'est la première fois que tu lances updatedb.
Reboot (pour vider le cache) et recommences.

Marcet

Ca veut dire que updatedb devrait être désactivé sur les machines ayant de petites config mémoire.

Vires /var/lib/slocate/slocate.db pour faire croire que c'est la première fois que tu lances updatedb.
Reboot (pour vider le cache) et recommences.

Je croyais que c'était mieux écrit que çà.

fmatias

Marcet a écrit:
Ca veut dire que updatedb devrait être désactivé sur les machines ayant de petites config mémoire.

Ou lancé toutes les semaines seulement et non tous les jours.

[supprimé]

Je réponds un peu en retard sur mon problème, désolé.
Le probème venait apparemment de cron, qui lançait des taches de fond tous les jours.
Du coup, j'ai viré ces travaux journaliers et les ai mis en mensuel.
Mon problème est donc solutionné.

Merci pour toutes ces indications.