Re: Gel provisoire du système lors d'un cp (et autres accès disque)
Le 28-09-2009, à 16:16:18 +0200, Jean-Yves F. Barbier (12ukwn@gmail.com) a écrit :
> steve a écrit :
> ...
> >> tu peux:
> >> * Tester le HD incriminé, dejà pour voir si son temps de formatage est normal,
> >
> > lui je le mets de côté pour le moment.
> >
> >> * virer le nouveau HD et le remplacer par l'ancien,
> >
> > c'est ce qui est en train de se passer
>
> je crois que je me suis mal expliqué: une fois que tout va bien (stable, array
> RAID pleinement opérationnel, etc) , virer l'un des HDz de l'array, et le
> remplacer par celui qui "a tout déclenché", histoire de voir si:
> 1- l'histoire se répète,
> 2- être sur que le PB venait du système mix
Attends, là tu parles de la debian toute fraîche ou le système que
j'essaie de réparer ? Car ya pu de debian toute fraîche, j'ai utilisé le
disque pour refaire le raid 1. Ce qui est fait d'ailleurs et en gros ça
n'a pas changé grand chose, les lenteurs persistent lors de la copie de
données d'un DVD (un fichier de 600Mb). J'ai fait des tests avec le
second lecteur dvd, même problème. Ensuite j'ai physiquement débranché
le lecteur DVD le plus lent et refait des tests, et là il semblait que
ça allait mais sans être parfait car après 10-15 secondes, le système se
figeait jusqu'à la fin de la copie. Ensuite, j'ai redémarré sur un
ancien noyau (2.6.26) et refait les tests. Comme avant. Et juste avant
de répondre à ce message, je me suis logué sous gnome, puis fluxbox en
pensant que c'était peut-être kde qui faisait des siennes, et bingo,
toujours pareil.
> >> * changer de contrôleur SATA,
> >> * les 2 derniers
> >
> > Je vérifie d'abord le nouveau raid et si ça foire toujours, j'inverse
> > les contrôleur sata.
>
> ok, mais plutôt que d'inverser, en choisir un autre (si c'est possible) serait
> mieux dans un premier temps.
C'est ce que j'ai fait, le port sata 1 sur lequel le HD défaillant était
branché n'a pas été utilisé pour le nouveau HD
> ...
> >> Non, vers 2003-4, il-y-a eu un PB avec les Maxtor DiamondMax série 9 qui
> >> touchait les boîtiers USB: le firmware de ces HDz n'était pas compatible
> >> avec certains chipsets de ces boîtiers.
> >> Cela arrive régulièrement (et c'est l'une des raisons, en dehors des bugs,
> >> pour laquelle le firmware n'est pas figé dans un MCP masqué.)
> >
> > Bon bon, on est en 2009, j'oserais espérer que ce genre de blagues
> > n'existait plus trop..
>
> au contraire: le hard est de plus en plus sophistiqué et "intelligent", ce qui
> veut dire que les firmwares sont de plus en plus gros et complexes; et comme
> beaucoup de boîtes agissent à l'arrache (style m$: te prennent pour un cobaye),
> les risques de bugs/incompatibilités augmentent régulièrement; sans compter la
> multiplication des "standards" qui se chevauchent, voire se télescopent...
Alors au niveau HD, y a-t-il des marques particulièrement sans surprise
pour des systèmes GNU/Linux ?
Reply to: