Bonsoir,
Merci pour les réponses.
Oplà, j'ai loupé pas mal...
Reprise et correction.
Xorg a écrit :Heu tu ne veux pas plutôt dire 500Mo/s par hasard ?
Oui, les essais effectués sur le SSD montent à 500 Mo/s.
Xorg a écrit :Sinon il y a une grosse confusion sur le modèle de ton processeur, car le socket LGA 1055 n'existe pas. J'avais pensé que tu avais fait une faute de frappe et que tu voulais écrire LGA 1155, or cela ne coïncide pas avec le modèle du processeur, car avec ce socket, les Core ix ont un nom de modèle à 4 chiffres et non 3 (Core ix 2xxx et Core ix 3xxx). Si c'est bel et bien un Core i3 550, alors c'est sur socket LGA 1156. Mais ça ne concorde pas avec la date, car en 2012 les Sandy Bridge étaient sur la marché (LGA 1155 donc).
Le petit proc est un i3-550 LGA1156 (confirmé sur le site d'Intel et par apport au modèle de la CM) sur une jetway NC-97-F en Mini-ITX. Oui, un peu vieux pour l'époque. Mais le revendeur jetway n'avait pas encore la CM pour y mettre un 1155.
benjarobin a écrit :Les 2 PC sont exactement à la même heure ? L'idéal est d'utiliser NTP
Nan, les deux PC ont 1 heure décalage. Je vais réinstaller la Debian (sous base GNU soit base BSD), et modifier ceci... (ceci explique celà, ou l'inverse)
benjarobin a écrit :Quelles sont les options complètes de ton exports ?
Le fichier export (sur le nas) est de ce type :
Code : Tout sélectionner
/media/Appart 192.168.2.30(rw,all_squash,anonuid=1000,anongid=100,sync)
benjarobin a écrit :De plus même un ancien core i3 est plus que largement surdimensionné pour faire un raid 1. Un pauvre Atom double cœur suffit.
Le core i3 est largement surdimensionné, mais il était prévu de faire du calcul partagé (je ne sais d’ailleurs toujours pas comment ça se passe. Faut dire que maintenant un mon petit proc, j'ai pas mal de puissance), et recycler le PC en poste client basique s’il le faut.
J'ai testé sinon des copies en SSD ↔ DD. Pour le SSD tout seul, les performances sont bien là. Mais en copiant avec le DD (base ou destination), le débit chute à 70 Mo/s.
Xorg a écrit :Par curiosité, tu as essayé de copier ce fichier du NAS sur le client puis ensuite d'ouvrir le fichier copié, pour voir si ça ne vient pas de LibreOffice ?
J'ai copié le fichier en question en local, modifier et recopié sur le NAS. Tout se passe bien (copie normale, modification sans plantage de LibreOffice).
Je vais également tester en SSHFS, voir un peu le résultat.
benjarobin a écrit :Après tu n'as pas de problème de droits ? Utilisateur et groupe id différent entre les 2 PC ?
J'ai mis les mêmes configurations (enfin, je crois) sur les différents postes clients. J'ai testé 4 « BASES » différentes (ArchLinux, Debian, Slackware, et SuSE), soit environ 10 systèmes différents avec quelques lives en plus sur 10 mois environ, sur 4 configurations différentes. Les soucis sous LibreOffice sont présents sur les derniers systèmes basés sur Archlinux (depuis les versions d'octobre 2012, mais je ne suis sur à 100 % de la date) et sous Slackware.
Je profite pour vous filer une info qui n'a l'air de rien, mais peut-être que ça pourra vous éclairer. Quand je souhaite éteindre mon NAS (accès par SSH depuis le poste client, et plusieurs commandes ont été testées dont
halt -p
ou
shutdown -h now
), à chaque fois c'est la même chose. Le processus de fin s’exécute bien, mais, nan. Le NAS reste allumé (confirmation que le processus se passe bien, car j'enregistre des fichiers d'allumage et d'extinction). Alors, que quand j'appuie sur le bouton d'arrêt (attention, pas pendant 30 secondes. Juste un appuie court), le processus se passe sans soucis. Et idem, il n'y a que sous Archlinux que ce souci est présent.
Je pense que sur la globalité du soucis, NFS n'est peut-être pas complétement innocent. Mais je doute qu'il soit tout seul. Je pense également au contrôleur réseau DHCPCD.
Pensez-vous que le contrôleur réseau puisse avoir un lien avec le problème ?
Merci pour vos réponses.
Bonne soirée.