D’où l’utilité d’utiliser les outils dédiés pour compiler le noyau…dans la distribu en propose. (merci de me pas troller à ce sujet ;))
Bon en attendant qu’ils me répare ext3 je particpe au portage d’une bibliothèque de transport indépendant pour NFS (pour faire du NFS sur n’importe quel protocole).
J’ai récupéré la partie userland dans FreeBSD. Ca avance bien, même si il y a de nombreux hics de portages.
Après il me faut faire le module de transport indépendant, moins drôle 
mais je ne serai pas seul 
Halala…les joies de portage…amuse toi
Peux tu me préciser un truc stp : ce trou de perfs de l’ext3, personne ne l’avais vu avant? C’est parce qu’il n’a lieu que dans un cas très particulier (taille de fichier) qu’il est passé inaperçu? En résumé : Une fois corrigé, est ce que ça va changer qqch l’utilisateur lambda d’ext3? (outre le fait qu’un trou de perf n’est pas acceptable dans un fs quelqu’il soit.)
Non, ce n’est pas un trou de perfs. C’est un bug du fsync.
En fait, lorsque tu fais un test sur un système de fichier réseau:
-tu crées un fichier depuis le client sur le serveur
-tu mesure le débit depuis la création jusqu’au fsync (c’est à dire que tu attends que le dernier octet soit écrit sur le disque)
Si tu n’attends pas le sync tu mesure seulement l’écriture dans la ram, donc l’efficacité de ton réseau, et ce n’est pas le but.
Or dans notre cas, le fsync de NFS fait appel au fsync du vfs qui fait lui même appel au fsync de ext3.
Comme mon le fsync de ext3 est boggué, certains appels au fsync retournent alors que les données sont encore dans le cache.
Ca donne des perfs impressionnantes (90Mo/s) mais qui ne correspondent à rien (si on mesure le fsync local, le débit maximal est de 46Mo/s pour mes disques en ext3)
En fait contrairement à ce que je pensais il n’y a pas de ‘trou’ de perfs pour les petits fichiers mais… des mesures invalides pour les grands fichiers.
Pour les grand fichiers le fsync retourne avant que les données soient réellement écrites, et mesurent un débit erronné.
Je ne sais pas si c’est plus clair?
Au fait ça avance ta thèse?
Je ne sais pas si c’est plus clair? C’est très clair (je ne rigole pas.)
Au fait ça avance ta thèse? Oui oui merci. J’en suis à reprendre les specification un par un et à expliquer pourquoi on va les tenir.
http://marc.theaimsgroup.com/?l=linux-kernel&m=109588458710859&w=2
2.6.9-rc2-mm2 (dsl pour le retard dans la mise à jour, en ce moement, je suis à la bourre…)
Encore un scheduler CPU.Andrew a l’air de l’apprécier:“It has a number of tunables and lots of documentation”
le mm3 est out 
… le bug du fsync n’est pas dans ext3.
Reste la vfs et … nfsv4!!!
http://marc.theaimsgroup.com/?l=linux-kernel&m=109601600311118&w=2
“This is a quick not-very-well-tested release - it can’t be worse than 2.6.9-rc2-mm2, which had a few networking problems.” Nous voila prevenus.
v_atekor : Si c’est dans vfs, ce serait bon que ce bug soit tuer rapidement… Si c’est dans nfsV4 aussi ceci dit… (bon ok mon commentaire ne sert à rien dsl :P. Je voulais juste dire que les bugs dans la vfs sont des horreurs à tuer au plus vite)
En même temps les bugs où qu’ils soient sont des horreurs à tuer au plus vite 
J’aimerai bien… Mais il faut d’abords que je sâche OU il est avant de pouvoir le corriger!
Je m’arrache les cheveux. C’est moyennement efficace pour le debogging, mais bon…
Ben quand tu n’auras plus de cheveux tu pourras te mettre à chercher
C’est sûr que tracker un bug dans le noyau n’est pas chose facile…surtout quand le bug se planque sous N couches…
Là j’en ai un dans v4l ou dans le support des cartes télé usb et je rame pour le tracker alors que les possibilités qu’il a de se planquer sont assez limitées.
2.6.9-rc2-mm4 à ce propos :
http://jcp.lespotos.com/images/Knode.jpg
[fixed]ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc2/2.6.9-rc2-mm4/
-
ppc64 builds are busted due to breakage in bk-pci.patch
-
sparc64 builds are busted too. Also due to pci problems.
-
Various updates to various things. In particular, a kswapd artifact which
could cause too much swapout was fixed. -
I shall be offline for most of this week.[/fixed]
J’ai un ptit problème assez étrange, sur une vielle machine qui fait office de serveur de fichier (NFS, ext3, Pentium 200MHz, 128Mo), le réseau se fige au bout d’un moment. Les ping passent de quelques ms à 10 sec et j’ai plus qu’à rebooter. J’ai un 2.6.8 dessus (essayé aussi avec un 2.6.9-rc2). Ça peut venir de la carte réseau (via-rhine) ou du noyau ??? J’ai la même carte réseau sur mon portable (en intégré par contre) et le même kernel et çamarche au poil… (faudra que je teste avec un 2.4 pour voir)(ça déconne aussi bien avec un switch qu’avec un cable croisé ou en utilisant SFTP…)
2.6.9-rc2-mm4
http://marc.theaimsgroup.com/?l=linux-kernel&m=109624785112152&w=2
Certains ont des pbs de boot avec ce noyau…
dumbledore : C’est dur de dire comme ça de quoi ça vient…
Que dit /var/log/messages ? syslog? Ca peut être un pb matériel tout comme ça peut être je ne sais quel bout de code qui se met à tourner en rond. Bref, sans logs point de salut
chez moi il boote bien
ou sinon essai avec un 2.6.8.1 car le 2.6.8 a un bug avec le nfs
Oui : pas de nfs possible avec un 2.6.8. Mais ce n’est pas ton cas : Toi, ça commence par marcher puis ça merdouille…
Topic Latest Love: 2.6.9-rc2-love4 : “We’re coming for you” - info + links: http://www.love-sources.org * redeeman’s LiveCD: http://tinyurl.com/3hf8k * pass rootflags=nopseudo rootfstype=reiser4 if you want apache2 to play nice on reiser4 * Happy B-Day DaMouse * nicksched is back