Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!news.mixmin.net!aioe.org!3my8gGK7ESrpx0+4iQgUXA.user.46.165.242.75.POSTED!not-for-mail From: Christophe PEREZ Newsgroups: fr.comp.os.linux.configuration Subject: Re: lenteur disque =?ISO-8859-15?Q?(=E0?= confirmer) Date: Tue, 7 Dec 2021 10:17:54 -0400 Organization: Aioe.org NNTP Server Message-ID: <20211207101754.6f76eb92@coffee.novazur.fr> References: <20211205191220.1c8dd5f5@coffee.novazur.fr> <20211206130208.4652f303@coffee.novazur.fr> <20211206161236.0c7af250@coffee.novazur.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Injection-Info: gioia.aioe.org; logging-data="19727"; posting-host="3my8gGK7ESrpx0+4iQgUXA.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; X-Newsreader: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) X-Notice: Filtered by postfilter v. 0.9.2 Bytes: 4045 Lines: 78 Le Tue, 7 Dec 2021 09:58:51 -0000 (UTC), Marc SCHAEFER a =E9crit : > Je ne suis plus s=FBr alors ce qu'est le hdparm que tu as montr=E9: disque > source ou disque destination? Disque source. Le disque destination ne peut pas =EAtre en cause, sinon il le serait pour tous les backups de tous les postes, et pas seulement celui-ci (je sais, je suis le seul =E0 le savoir, mais je ne l'ai pas mis en cause justement parce que je le sais ;) . > un petit sch=E9ma: >=20 >=20 > machine 1 ---------- r=E9seau --------------- machine 2 > | | > disque 1 disque 2 C'est =E7a. > Ah oui, cette information manquait. D=E9sol=E9. Grossi=E8re omission, mais =E7a venait du fait que j'avais =E9c= art=E9 la piste du r=E9seau trop t=F4t. J'avais fait un test sur t=E9l=E9chargemen= t de fichier de mon serveur http, mais sans doute fichier trop petit (18Mo), je n'avais pas plus gros sous la main =E0 ce moment. Et le temps =E9tait le m=EAme sur les 2 machines. J'ai d=E9duit trop vite. > > D=E9faillance de la carte r=E9seau int=E9gr=E9e ? =20 >=20 > Tu peux regarder les compteurs d'erreur (netstat -i). $ netstat -i Table d'interfaces noyau Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP = TX-OVR Flg eth0 1500 747186 0 0 0 97050 0 0 = 0 BMRU lo 65536 790 0 0 0 790 0 0 = 0 LRU J'en d=E9duis que ce n'est pas la carte r=E9seau la cause. > Tu peux aussi =E9ventuellement v=E9rifier que tu as bien le paquet > firmware de ta carte r=E9seau. Non, =E7a non :) Il tourne comme =E7a depuis 2006. Pas de raison que =E7a vienne de la. De plus, c'est un module du noyau. Et comme je l'ai dit initialement, rien n'a =E9t=E9 modifi=E9 logiciellement avant la d=E9failla= nce. > Tu peux changer les c=E2bles et le port du switch. Le c=E2ble c'est compliqu=E9. Il faut que je d=E9place la machine pour la tester sur un autre c=E2ble. C'est pr=E9vu. Pour le port du switch, j'y ai pens=E9, mais je n'=E9tais pas s=FBr que =E7a puisse avoir une influence. J'ai =E9teint et rallum=E9 le switch sans succ=E8s, mais pour changer de port, c'est un tout petit peu plus compliqu=E9. Je vais m'y ateler. > Ce qui arrive parfois est que la n=E9gociation boucle: sympt=F4me, plein > de up/down dans dmesg (que tu n'as pas observ=E9). Moi je ne vois rien. http://dpaste.com/8EJ6NMCJ6 > Le d=E9bit n=E9goci=E9 est correct. >=20 > Conclusion: oui, c'est le r=E9seau, probablement le c=E2ble. Sans doute, =E0 moins que le switch soit en cause, comme =E9voqu=E9. Merci pour ton aide au diagnostique. Je reviendrai quand j'aurai pu faire les manipulations.