Pour tous ceux qui ont des doutes sur la programmation en bépo, je vous conseille le Bépo-altgrsym-3.
Faite par un technicien pour les techniciens : l’idée étant de rendre AltGr symétrique (d’où le nom), ce qui permet de rendre accessible les caractères spéciaux utilisés en prog, shell, etc.
Seul bémol : faudrait que je me bouge pour sortir un Bépo-altgrsym-4 qui limiterait au minimum nécessaire les changements de touche vis-à-vis de la 1.0. Histoire de limiter la casse quand on est sur son ordi, mais que le bépo officiel (1.0) est dispo avec un coup de setxkbmap/loadkeys.
Il y a longtemps que des gens demandent ça, mais personne semble assez motivé pour le coder. Faut dire que gérer tous les cas serait bien complexe.
La tendance c’est plutôt de placer les modifs locales dans des fichiers qui seront chargés, mais qui ne font pas partie des paquets. Du coup, plus de diff à gérer, mais on peut se retrouver avec une config qui n’est plus adaptée à la version du logiciel, des options qui n’existent plus, etc. Donc y’a pas de solution miracle.
Exemples :
/etc/sudoers.d/local au lieu de taper dans /etc/sudoers
/etc/bind/named.conf.local au lieu de taper dans /etc/bind/named.conf
/etc/apache2/conf.d/local au lieu de taper dans /etc/apache2/apache2.conf
/etc/vim/vimrc.local au lieu de taper dans /etc/vim/vimrc
Etc.
J’ai pas eu à modifier la config de PHP depuis longtemps, mais en jetant un œil je vois /etc/php5/apache2/conf.d/. Teste en créant un fichier dans ce répertoire, et places y tes modifs locales.
Seule /home, sur le HD, est en LUKS. / est sur le SSD sans LUKS, et y’a aussi le problème de débit.
la lecture est rapide parce que les données sont dechiffrées quand tu rentres dans le dossier l'ecriture est plus lente parce qu'il faut recevoir les données, les cryptées puis les stocker (ou les stocker puis crypter les blocs selon ou se trouve le cryptage)
Qu’est-ce que tu entends par « les données sont dechiffrées quand tu rentres dans le dossier » ? J’ai pas suivi ta démonstration, je vois pas pourquoi décrypter serait plus rapide que crypter.
si tu as du LVM, essaie de faire une partition en dehors de LUKS et regarde si tu as toujours tes lenteurs quand tu ecris sur cette nouvelle partition.
La config recommandée c’est LUKS+LVM plutôt que LVM+LUKS, et c’est ce que j’ai fait. Donc j’ai un volume LUKS sur tout le HD.
Mais comme dit plus haut, sans LUKS et sur un autre disque, ça rame pareil.
c'est difficile de bousiller sa carte mère en mettant à jour son BIOS. Je me demande comment ton pote s'y est pris.
Renseignements pris, c’était une Gigabyte pas une Asus, et il s’agissait d’une série semi-pro mal testée et peu vendue. Mais par contre, aux débuts des amd64, c’était bien avec Asus qu’il y a eu plein de problèmes.
C'est pourtant bien une chose extrêmement importante à faire dans ton cas. Si ça se trouve le BIOS corrige un bug errata du chipset…
Ce qui me refroidit, c’est que lorsqu’on a une merde logicielle on tire la sauvegarde. Quand on a une panne matos, soit on renvoit en SAV (donc indisponibilité d’une semaine au grand minimum), soit on jette et on remplace, et il faut attendre que le nouveau matos arrive, le monter, le tester, etc.
Certes, on peut faire de la récup pour avoir des pièces détachées, ou être à l’affut des bons plans pour avoir du spare sous la main, voir même tout acheter en double. Mais dans tous les cas, ça demande du temps et/ou de l’argent… Ça se sent que j’aime pas le matos et que je préfère la partie logicielle ? :)
Avec le test hdparm et le fait que le réseau semblait pas touché, je pensais que le problème était logiciel (du genre bug dans le VFS, ou un truc comme ça), pas matériel. Du coup, l’intérêt de flasher le bios me semblait limité.
Sauf qu’en fait, tout ce que le test hdparm et le réseau montrent, c’est que le problème se pose uniquement à l’écriture (voir mon commentaire plus haut). Donc, ça pourrait venir du matos, finalement.
comment savoir, les changelogs ASUS sont complètement bidons.
Ouais, j’étais déjà allé sur leur site pour voir si le changelog d’une màj bios comportait une mention qui évoquait mon problème. J’ai pu constater à quel point c’est laconique, on a que 2 types de màj : « Improve system stability » ou « Support new CPUs ». Paye tes détails…
Je suis partisan de mettre à jour son BIOS quand il y a une mise à jour (sauf si le changelog est suffisamment explicite pour voir que cela n'est pas pertinent bien sûr).
Et je suis partisan de pas réparer ce qui marche :)
Mais là, ça ne marche pas. Donc, à moins que quelqu’un ait une autre idée, je vais monter une machine de secours au cas où, et je vais tenter la màj du bios. Je vous tiendrais au courant quand ça sera fait. Ici en commentaire si ça marche ; avec un nouveau journal si ça continue à déconner, pour récolter de nouveaux avis.
J’ai aussi testé avec un livecd fedora
En 32 ou 64 bits ?
En 64 bits. Mais comme j’ai dit, le test n’a pas été assez long pour être réellement concluant (juste une nuit, alors que certaines fois le problème démarre après plusieurs jours d’uptimes).
Tu as une raison particulière de fonctionner en 32 bits ?
J’ai installé le système de ma machine perso il y a (très) longtemps, et depuis je l’ai dist-upgradé. Avant l’époque de puppet, je m’embêtais à réinstaller et tout reconfigurer pour d’autres machines. D’une part, après une réinstall, pendant plusieurs semaines je tombais en permanence sur des paquets que j’avais oublié d’installer ou de personnaliser sur le nouveau système. D’autre part, j’ai constaté que lorsque j’avais des bugs sur ma machine perso (qui avait été dist-upgradée au lieu d’être réinstallée), je retrouvais exactement les mêmes bugs sur les systèmes "neufs". Conclusion, je vois pas l’intérêt de passer du temps à installer des paquets manuellement et refaire les configs, si on obtient le même état en faisant dist-upgrade.
Depuis, pour le premier point, de nos jours y’a puppet et compagnie. Sauf que sur ma machine de bureau, j’ai pas mal de trucs personnalisés (et non, tout ce qui est personnalisé n’est pas nécessairement dans ~) et beaucoup ne sont pas dans puppet : à commencer par tout ce qui n’est que sur cette machine de bureau.
Il faudra que je passe en 64 bits un jour, mais pour l’instant avec le PAE, les avantages du 64 bits me semblent pas justifier le temps que ça prendrait de tout reconfigurer sur ma machine perso.
Je ne suis pas spécialiste en matos, mais ça me semble peu probable que deux disques créent un problème de débit en écriture, juste parce qu’ils seraient incompatibles entre eux ? En SATA, chaque disque a sa propre nappe…
J’ai / sur le SSD et /home sur le HD. J’ai pas la place de copier /home sur le SSD, et le HD est en LUKS+LVM, et je préfère éviter de rajouter LUKS dans ma séquence de boot (et par le passé, grub m’a déjà embêté avec LVM).
De plus, même si j’étais pas frileux, repartionner le LVM et tout configurer pour booter en LUKS, lire la doc, tout bien tester, etc me demandera sans doute autant de temps qu’installer une autre distrib et faire des tests de copie en boucle. À la limite le 2ème cas me demanderait moins de temps, en fait : dans les deux cas, l’ordi serait pas dispo mais dans le 2ème cas je pourrais faire autre chose, à condition que ça soit pas sur l’ordi. Sauf que pour bosser, j’ai besoin de l’ordi.
À part l’affichage (qui serait à priori un autre problème) tu as concrètement des problèmes de lenteur quand ça écrit ou lit sur le disque ?
Yep, je poste un journal parce que l’utilisation de tous les jours est assez pénible, les performances des trucs habituels (copie de fichiers, etc) sont à la ramasse.
Je suis pas un fana de perfs, et si j’ai dégaîné dd c’était pour objectiver mon impression. Quand j’ai vu le résultat, je me suis dit « ah ben tu m’étonnes que ça rame, forcement ! »
C'est l'écriture dont il parle.
Tiens tiens, je n’avais pas percuté que le problème se posait uniquement en écriture. Si j’ai moins de problèmes quand j’utilise scp, c’est pas une question de réseau, c’est parce que je l’utilise 99% du temps en lecture (de ma machine de bureau vers une autre).
Comme les deux disques (SSD et HD) sont touchés par ce problème de débits en écriture, un test de lecture sur un disque sera forcement bridé par l’écriture sur l’autre disque.
Et donc, en réseau on retrouve le problème en écriture :
Du coup, ça relance la piste du problème matériel, que je pensais écartée avec le test hdparm.
Oui, c’est pour ça que je demande. Ça peut modifier les performances de dd
Je suis pas spécialiste du matos et des couches basses, mais il me semble que les applications ne sont pas concernées par les tailles de blocs ou secteurs. Si les options de dd pouvaient fausser le diagnostic, ça veut dire que cp, mv et autres coreutils comploteraient pour sélectionner une mauvaise taille de blocs/secteurs. Idem pour firefox, qui rame comme une loutre bourrée par moment. J’imagine que c’est lorsqu’il a besoin de faire plein d’écritures sur sa base sqlite.
J’ai des perfs pourries à l’utilisation et c’est ça mon problème, je ne cherche pas à optimiser un test pour que dd m’affiche la plus grosse valeur possible avec mon matériel ;-)
Sinon on m’avait posé une question sur la taille des blocs sur un journal précédent, voici les tests que j’avais fait :
Si j’ai posté un journal, c’est que j’ai des performances (très) dégradées en utilisation normale. J’ai des perfs pourries de manière aléatoire, mais quelques jours après un reboot, ça se stabilise sur « perfs pourries en permanence ». Et comme je reboot que lorsque c’est strictement nécessaire, ben j’ai des perfs pourries en permanence, ce qui devient lourd.
tu lui demande de faire un fichier de 1Go en une fois (bs = block size)
je doute que tes disques aient des secteurs aussi gros.
Je suis pas spécialiste du matos et des couches basses, mais la taille des blocs/secteurs c’est un truc de FS, pas d’applicatif. Si tu penses que les options de dd pourraient fausser le diagnostic, ça veut dire que tu penses à un complot de cp, mv et autres coreutils pour sélectionner une mauvaise taille de blocs/secteurs eux aussi. Et ça vaut aussi pour ff, qui rame comme une loutre bourrée par moment.
Quelques heures après le démarrage, les perfs du SSD sont déjà dégradées même quand ça beugue pas encore complètement. C’est plus faiblard que ce que ça devrait, le SSD se comporte presque comme un HD…
pourquoi jessie avec noyau backport ?
la machine ne fonctionne-t-elle pas avec le noyau par defaut ?
Le GPU intégré demande un noyau plus récent que celui de jessie. Et pour avoir le support du matos récent, faut un noyau récent, c’est logique.
de plus ton noyau backport c'est un noyau 686-pae, pourquoi ne pas avoir installé ta machine en 64bits ? (cela ne devrait pas jouer sur les performances du disque)
Parce que ce système a été installé il y a (très très) longtemps, et dist-upgradé depuis (et je compte plus les changements de disques).
pas forcement besoin d'installer une nouvelle distrib
il faut juste demarrer sur un liveCD/liveUSB, monter le disque dur et faire les tests que tu fais deja.
Parce que, comme je l’ai expliqué, « c’est ma machine principale, et ça m’ennuierait de devoir installer + utiliser pendant plusieurs heures un autre OS, juste pour savoir si ça fait la même chose. »
C’est pas l’installation qui m’ennuie. Aujourd’hui l’ordi est utilisable, même si ce problème devient pénible à la longue, mais globalement ça va, et j’ai du boulot, pas mal de choses à faire avancer. Ça serait casse-pied de fermer ma session, et d’être bloqué sur un autre système le temps des tests. Étant donné que c’est aléatoire, il faudrait rester plusieurs jours sans accès à mon environnement habituel pour confirmer que le problème n’apparaît pas avec un autre système.
Donc si jamais je peux éviter, je suis preneur.
nouvelle machine, ancien disque,
tu as reglé comme il faut le bios pour dire si c'est un SSD ou un HDD ? pour activer le sata3 (6Gbps)…
Le SATA est en mode AHCI (la seule autre option, c’est RAID et ça je sais que je veux pas). Ensuite il y a 2 options pour chacun des 6 ports SATA disponibles : une option pour désactiver, une autre pour spécifier si le port est hotplug ou pas. Les 6 ports sont activés, avec hotplug désactivé.
C’est un problème de performances, pas de secteurs défecteux. Je n’avais pas de problème de performances avec ce HD quand il était sur une autre carte mère, et de plus le problème concerne aussi le SSD.
Device Start End Sectors Size Type
/dev/sdb1 2048 5860533134 5860531087 2,7T Linux LVM
Mais est-ce que c’est grave, étant donné que 512 et 4096 sont multiples comme tu le soulignes ? Je n’avais pas de problème de performances avec ce HD quand il était sur une autre carte mère, et de plus le problème concerne aussi le SSD.
[^] # Re: Mainteneur, communauté et BÉPO
Posté par Ytos . En réponse au journal 6 ans de projets libres: bilan et bien être du mainteneur. Évalué à -1.
Pour tous ceux qui ont des doutes sur la programmation en bépo, je vous conseille le Bépo-altgrsym-3.
Faite par un technicien pour les techniciens : l’idée étant de rendre AltGr symétrique (d’où le nom), ce qui permet de rendre accessible les caractères spéciaux utilisés en prog, shell, etc.
Seul bémol : faudrait que je me bouge pour sortir un Bépo-altgrsym-4 qui limiterait au minimum nécessaire les changements de touche vis-à-vis de la 1.0. Histoire de limiter la casse quand on est sur son ordi, mais que le bépo officiel (1.0) est dispo avec un coup de setxkbmap/loadkeys.
# Ça n’existe pas
Posté par Ytos . En réponse au message Fusion interactive des fichiers de configuration lors d'une mise à jour. Évalué à 1.
Il y a longtemps que des gens demandent ça, mais personne semble assez motivé pour le coder. Faut dire que gérer tous les cas serait bien complexe.
La tendance c’est plutôt de placer les modifs locales dans des fichiers qui seront chargés, mais qui ne font pas partie des paquets. Du coup, plus de diff à gérer, mais on peut se retrouver avec une config qui n’est plus adaptée à la version du logiciel, des options qui n’existent plus, etc. Donc y’a pas de solution miracle.
Exemples :
/etc/sudoers.d/local au lieu de taper dans /etc/sudoers
/etc/bind/named.conf.local au lieu de taper dans /etc/bind/named.conf
/etc/apache2/conf.d/local au lieu de taper dans /etc/apache2/apache2.conf
/etc/vim/vimrc.local au lieu de taper dans /etc/vim/vimrc
Etc.
J’ai pas eu à modifier la config de PHP depuis longtemps, mais en jetant un œil je vois /etc/php5/apache2/conf.d/. Teste en créant un fichier dans ce répertoire, et places y tes modifs locales.
[^] # Re: Idée...
Posté par Ytos . En réponse au message Débit ridicule HD et SSD (suite). Évalué à 1.
Seule /home, sur le HD, est en LUKS. / est sur le SSD sans LUKS, et y’a aussi le problème de débit.
Qu’est-ce que tu entends par « les données sont dechiffrées quand tu rentres dans le dossier » ? J’ai pas suivi ta démonstration, je vois pas pourquoi décrypter serait plus rapide que crypter.
La config recommandée c’est LUKS+LVM plutôt que LVM+LUKS, et c’est ce que j’ai fait. Donc j’ai un volume LUKS sur tout le HD.
Mais comme dit plus haut, sans LUKS et sur un autre disque, ça rame pareil.
[^] # Re: BIOS / x86-64
Posté par Ytos . En réponse au message Débit ridicule HD et SSD (suite). Évalué à 1.
Renseignements pris, c’était une Gigabyte pas une Asus, et il s’agissait d’une série semi-pro mal testée et peu vendue. Mais par contre, aux débuts des amd64, c’était bien avec Asus qu’il y a eu plein de problèmes.
Ce qui me refroidit, c’est que lorsqu’on a une merde logicielle on tire la sauvegarde. Quand on a une panne matos, soit on renvoit en SAV (donc indisponibilité d’une semaine au grand minimum), soit on jette et on remplace, et il faut attendre que le nouveau matos arrive, le monter, le tester, etc.
Certes, on peut faire de la récup pour avoir des pièces détachées, ou être à l’affut des bons plans pour avoir du spare sous la main, voir même tout acheter en double. Mais dans tous les cas, ça demande du temps et/ou de l’argent… Ça se sent que j’aime pas le matos et que je préfère la partie logicielle ? :)
Avec le test hdparm et le fait que le réseau semblait pas touché, je pensais que le problème était logiciel (du genre bug dans le VFS, ou un truc comme ça), pas matériel. Du coup, l’intérêt de flasher le bios me semblait limité.
Sauf qu’en fait, tout ce que le test hdparm et le réseau montrent, c’est que le problème se pose uniquement à l’écriture (voir mon commentaire plus haut). Donc, ça pourrait venir du matos, finalement.
Ouais, j’étais déjà allé sur leur site pour voir si le changelog d’une màj bios comportait une mention qui évoquait mon problème. J’ai pu constater à quel point c’est laconique, on a que 2 types de màj : « Improve system stability » ou « Support new CPUs ». Paye tes détails…
https://www.asus.com/Motherboards/H170-PRO-GAMING/HelpDesk_Download/
Et je suis partisan de pas réparer ce qui marche :)
Mais là, ça ne marche pas. Donc, à moins que quelqu’un ait une autre idée, je vais monter une machine de secours au cas où, et je vais tenter la màj du bios. Je vous tiendrais au courant quand ça sera fait. Ici en commentaire si ça marche ; avec un nouveau journal si ça continue à déconner, pour récolter de nouveaux avis.
J’ai installé le système de ma machine perso il y a (très) longtemps, et depuis je l’ai dist-upgradé. Avant l’époque de puppet, je m’embêtais à réinstaller et tout reconfigurer pour d’autres machines. D’une part, après une réinstall, pendant plusieurs semaines je tombais en permanence sur des paquets que j’avais oublié d’installer ou de personnaliser sur le nouveau système. D’autre part, j’ai constaté que lorsque j’avais des bugs sur ma machine perso (qui avait été dist-upgradée au lieu d’être réinstallée), je retrouvais exactement les mêmes bugs sur les systèmes "neufs". Conclusion, je vois pas l’intérêt de passer du temps à installer des paquets manuellement et refaire les configs, si on obtient le même état en faisant dist-upgrade.
Depuis, pour le premier point, de nos jours y’a puppet et compagnie. Sauf que sur ma machine de bureau, j’ai pas mal de trucs personnalisés (et non, tout ce qui est personnalisé n’est pas nécessairement dans ~) et beaucoup ne sont pas dans puppet : à commencer par tout ce qui n’est que sur cette machine de bureau.
Il faudra que je passe en 64 bits un jour, mais pour l’instant avec le PAE, les avantages du 64 bits me semblent pas justifier le temps que ça prendrait de tout reconfigurer sur ma machine perso.
[^] # Re: Idée...
Posté par Ytos . En réponse au message Débit ridicule HD et SSD (suite). Évalué à 1.
Je ne suis pas spécialiste en matos, mais ça me semble peu probable que deux disques créent un problème de débit en écriture, juste parce qu’ils seraient incompatibles entre eux ? En SATA, chaque disque a sa propre nappe…
J’ai / sur le SSD et /home sur le HD. J’ai pas la place de copier /home sur le SSD, et le HD est en LUKS+LVM, et je préfère éviter de rajouter LUKS dans ma séquence de boot (et par le passé, grub m’a déjà embêté avec LVM).
De plus, même si j’étais pas frileux, repartionner le LVM et tout configurer pour booter en LUKS, lire la doc, tout bien tester, etc me demandera sans doute autant de temps qu’installer une autre distrib et faire des tests de copie en boucle. À la limite le 2ème cas me demanderait moins de temps, en fait : dans les deux cas, l’ordi serait pas dispo mais dans le 2ème cas je pourrais faire autre chose, à condition que ça soit pas sur l’ordi. Sauf que pour bosser, j’ai besoin de l’ordi.
[^] # Re: surchauffe?
Posté par Ytos . En réponse au message Débit ridicule HD et SSD (suite). Évalué à 1.
A priori, non :
De plus, quand je place la main devant le ventilo de l’alim, l’air n’est pas chaud.
[^] # Re: Salut
Posté par Ytos . En réponse au message Débit ridicule HD et SSD (suite). Évalué à 2. Dernière modification le 27 novembre 2016 à 14:15.
Yep, je poste un journal parce que l’utilisation de tous les jours est assez pénible, les performances des trucs habituels (copie de fichiers, etc) sont à la ramasse.
Je suis pas un fana de perfs, et si j’ai dégaîné dd c’était pour objectiver mon impression. Quand j’ai vu le résultat, je me suis dit « ah ben tu m’étonnes que ça rame, forcement ! »
Tiens tiens, je n’avais pas percuté que le problème se posait uniquement en écriture. Si j’ai moins de problèmes quand j’utilise scp, c’est pas une question de réseau, c’est parce que je l’utilise 99% du temps en lecture (de ma machine de bureau vers une autre).
Comme les deux disques (SSD et HD) sont touchés par ce problème de débits en écriture, un test de lecture sur un disque sera forcement bridé par l’écriture sur l’autre disque.
Et donc, en réseau on retrouve le problème en écriture :
Du coup, ça relance la piste du problème matériel, que je pensais écartée avec le test hdparm.
Je suis pas spécialiste du matos et des couches basses, mais il me semble que les applications ne sont pas concernées par les tailles de blocs ou secteurs. Si les options de dd pouvaient fausser le diagnostic, ça veut dire que cp, mv et autres coreutils comploteraient pour sélectionner une mauvaise taille de blocs/secteurs. Idem pour firefox, qui rame comme une loutre bourrée par moment. J’imagine que c’est lorsqu’il a besoin de faire plein d’écritures sur sa base sqlite.
J’ai des perfs pourries à l’utilisation et c’est ça mon problème, je ne cherche pas à optimiser un test pour que dd m’affiche la plus grosse valeur possible avec mon matériel ;-)
Sinon on m’avait posé une question sur la taille des blocs sur un journal précédent, voici les tests que j’avais fait :
https://linuxfr.org/nodes/109175/comments/1665759
[^] # Re: deja pourquoi ?
Posté par Ytos . En réponse au message Débit ridicule du disque. Évalué à 1.
Effectivement, en « SATA Mode Selection » j’ai le choix entre AHCI ou RAID.
C’est bien le cas.
[^] # Re: deja pourquoi ?
Posté par Ytos . En réponse au message Débit ridicule du disque. Évalué à 1.
Si j’ai posté un journal, c’est que j’ai des performances (très) dégradées en utilisation normale. J’ai des perfs pourries de manière aléatoire, mais quelques jours après un reboot, ça se stabilise sur « perfs pourries en permanence ». Et comme je reboot que lorsque c’est strictement nécessaire, ben j’ai des perfs pourries en permanence, ce qui devient lourd.
Je suis pas spécialiste du matos et des couches basses, mais la taille des blocs/secteurs c’est un truc de FS, pas d’applicatif. Si tu penses que les options de dd pourraient fausser le diagnostic, ça veut dire que tu penses à un complot de cp, mv et autres coreutils pour sélectionner une mauvaise taille de blocs/secteurs eux aussi. Et ça vaut aussi pour ff, qui rame comme une loutre bourrée par moment.
Mais bon, j’ai aussi fait le test avec bs=1M.
SSD juste après un reboot :
% dd if=/dev/zero of=/tmp/test1.img bs=1M count=1000
1000+0 enregistrements lus
1000+0 enregistrements écrits
1048576000 octets (1,0 GB) copiés, 2,21327 s, 474 MB/s
Quelques heures après le démarrage, les perfs du SSD sont déjà dégradées même quand ça beugue pas encore complètement. C’est plus faiblard que ce que ça devrait, le SSD se comporte presque comme un HD…
% dd if=/dev/zero of=/tmp/test1.img bs=1M count=1000
1000+0 enregistrements lus
1000+0 enregistrements écrits
1048576000 octets (1,0 GB) copiés, 6,16263 s, 170 MB/s
Le HD quand ça beugue pas :
% dd if=/dev/zero of=test1.img bs=1M count=1000
1000+0 enregistrements lus
1000+0 enregistrements écrits
1048576000 octets (1,0 GB) copiés, 9,93859 s, 106 MB/s
Que ça soit sur le SSD ou sur le disque, quand ça beugue :
(of=/tmp/test1.img c’est le SSD, of=test1.img c’est le HD)
% dd if=/dev/zero of=/tmp/test1.img bs=1M count=1000
1000+0 enregistrements lus
1000+0 enregistrements écrits
1048576000 octets (1,0 GB) copiés, 625,015 s, 1,7 MB/s
% dd if=/dev/zero of=test1.img bs=1M count=1000
1000+0 enregistrements lus
1000+0 enregistrements écrits
1048576000 octets (1,0 GB) copiés, 618,308 s, 1,7 MB/s
Le GPU intégré demande un noyau plus récent que celui de jessie. Et pour avoir le support du matos récent, faut un noyau récent, c’est logique.
Parce que ce système a été installé il y a (très très) longtemps, et dist-upgradé depuis (et je compte plus les changements de disques).
Parce que, comme je l’ai expliqué, « c’est ma machine principale, et ça m’ennuierait de devoir installer + utiliser pendant plusieurs heures un autre OS, juste pour savoir si ça fait la même chose. »
C’est pas l’installation qui m’ennuie. Aujourd’hui l’ordi est utilisable, même si ce problème devient pénible à la longue, mais globalement ça va, et j’ai du boulot, pas mal de choses à faire avancer. Ça serait casse-pied de fermer ma session, et d’être bloqué sur un autre système le temps des tests. Étant donné que c’est aléatoire, il faudrait rester plusieurs jours sans accès à mon environnement habituel pour confirmer que le problème n’apparaît pas avec un autre système.
Donc si jamais je peux éviter, je suis preneur.
Le SATA est en mode AHCI (la seule autre option, c’est RAID et ça je sais que je veux pas). Ensuite il y a 2 options pour chacun des 6 ports SATA disponibles : une option pour désactiver, une autre pour spécifier si le port est hotplug ou pas. Les 6 ports sont activés, avec hotplug désactivé.
[^] # Re: Quels secteur ?
Posté par Ytos . En réponse au message Débit ridicule du disque. Évalué à 1.
C’est un problème de performances, pas de secteurs défecteux. Je n’avais pas de problème de performances avec ce HD quand il était sur une autre carte mère, et de plus le problème concerne aussi le SSD.
[^] # Re: Alignement ?
Posté par Ytos . En réponse au message Débit ridicule du disque. Évalué à 1.
Pour le SSD, la sortie de fdisk est similaire à ta config :
# fdisk -lu /dev/sda
Disk /dev/sda: 223,6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000c361a
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 429686783 429684736 204,9G 83 Linux
Par contre pour le HD, c’est en 4096 mais avec un 512 qui traîne au milieu :
# fdisk -lu /dev/sdb
Disk /dev/sdb: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 525482F6-EA1A-4EF3-8E6E-A0603ACC91F8
Device Start End Sectors Size Type
/dev/sdb1 2048 5860533134 5860531087 2,7T Linux LVM
Mais est-ce que c’est grave, étant donné que 512 et 4096 sont multiples comme tu le soulignes ? Je n’avais pas de problème de performances avec ce HD quand il était sur une autre carte mère, et de plus le problème concerne aussi le SSD.