Xfennec a écrit 88 commentaires

A mon avis, c'est parce que ce n'est pas au Kernel de gérer ça.

La récursivité, c'est quelque chose qu'il est possible d'implémenter au niveau de l'espace utilisateur. Du coup, peut-être manque-t-il une API un peu plus haut niveau pour répondre à ces besoins manifestement récurrents ?

Pour la liste de ce qui est « surveillé par inotify », la piste la plus intéressante est probablement /proc (une autre étant lsof)

Les processus qui font appel à l'API montre un fd qui pointe vers anon_inode:inotify. Exemple : find /proc/*/fd/* -lname 'anon_inode:inotify'. C'est une « instance » inotify (inotify_init()).

Il suffit alors d'aller voir le fdinfo correspondant pour voir quels inodes sont surveillées :

$ cat /proc/2006/fdinfo/13
pos:    0
flags:  02000000
inotify wd:1 ino:60334 sdev:fd00002 mask:800afc6 ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:340306004ca43e19

Ici c'est l'inode 0x60334 (/home/xfennec/.kde/share/apps/korganizer/std.ics, c'est un « watch » inotify). Si c'est un répertoire, c'est l'ensemble de son contenu « direct » (de niveau 1, quoi) qui est surveillé.

Ça semble plus être un problème du coté de pyinotify qu'une bizarrerie de l'API :

$ inotifywait -rm /tmp/inotify/
[...]

$ mkdir /tmp/inotify/aze
/tmp/inotify/ CREATE,ISDIR aze
/tmp/inotify/ OPEN,ISDIR aze
/tmp/inotify/ CLOSE_NOWRITE,CLOSE,ISDIR aze

$ touch /tmp/inotify/aze/k
/tmp/inotify/aze/ CREATE k
/tmp/inotify/aze/ OPEN k
/tmp/inotify/aze/ ATTRIB k
/tmp/inotify/aze/ CLOSE_WRITE,CLOSE k

$ mv /tmp/inotify/aze /tmp/
/tmp/inotify/ MOVED_FROM,ISDIR aze
/tmp/inotify/aze/ MOVE_SELF 

$ mv /tmp/aze /tmp/inotify/
/tmp/inotify/ MOVED_TO,ISDIR aze
/tmp/inotify/ OPEN,ISDIR aze
/tmp/inotify/ CLOSE_NOWRITE,CLOSE,ISDIR aze

(inotifywait 3.14, Kernel 3.9.10)

Pas de plainte lorsque le répertoire s'en va (le parent autant que le répertoire lui-même "voient" l'événement) et pas de problème particulier lorsque le répertoire revient.

D'ailleurs inotifywait se débrouille pour ajouter à nouveau des watches dans ce répertoire (parce qu’il est en mode récursif, j'imagine) :

$ ls -l /proc/$(pidof inotifywait)/fd  | grep anon_inode:inotify
lr-x------ 1 xfennec xfennec 64 25 nov.  15:37 3 -> anon_inode:inotify

$ cat /proc/$(pidof inotifywait)/fdinfo/3 | grep inotify
inotify wd:4 ino:162801 sdev:fd00001 mask:800afff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:01281600a35a90fa
inotify wd:2 ino:162195 sdev:fd00001 mask:800afff ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:952116009d5a90fa

ls -lai /tmp/inotify/
1450389 drwxrwxr-x   4 xfennec xfennec  4096 25 nov.  15:48 .
1438977 drwxrwxrwt. 34 root    root    20480 25 nov.  15:47 ..
1452033 drwxrwxr-x   2 xfennec xfennec  4096 25 nov.  15:35 aze

0x162801 = 1452033 (/tmp/inotify/aze)
0x162195 = 1450389 (/tmp/inotify)

A priori, un appel à fstrim après la copie sur le SSD va rétablir la situation, non ? (à moins que cette commande ne fonctionne qu'en "relatif" par rapport à son dernière appel … auquel cas il existe peut-être un moyen de refaire une passe complète)

Bhen … non.

J'ai trouvé toutes sortes de réponses alambiquées à propos de rsync, mais celle là, non. C'est simple et ça fait pile ce que je voulais.

Merci !

J'aurai dû développer plus la phrase concernant les solutions que j'avais trouvé avant de coder ce petit outil :)

Comme indiqué, rsync fait effectivement partie des solutions souvent évoquées pour résoudre ce problème, mais il faut avouer que la syntaxe résultante manque un tout petit peu de légèreté, non ? (moi je ne maîtrise pas assez rsync pour lancer truc comme ça sans avoir consulté chaque option au préalable)

L'astuce est assez géniale (accumuler les valeurs de retour de write(2) pour compter les octets) et bien réalisée !(du awk joli, c'est pas tous les jours)

Mais passer par strace, ça tue pas un peu les performances ?

Tu as tout à fait raison, la copie d'arborescence ne va rien donner d'intéressant (ça va afficher le fichier en cours, tout simplement).

Je ne connaissais pas gcp (et c'est bien dommage, ça semble particulièrement complet, beau boulot !) et cv ne joue pas du tout dans la même catégorie : c'est vraiment un modeste petit outil de « monitoring » : on ne change rien aux commandes et aux habitudes.

En fait, cv, c'est typiquement l'outil sur lequel j'aurais souhaité tomber après avoir lancé ma fameuse copie « error prone » : on télécharge, on compile et on surveille la copie sans la relancer :)

Il s'agit de powerline-shell (https://github.com/milkbikis/powerline-shell) , découvert sur LinuxFR au hasard d'un autre journal.

J'utilise le thème par défaut et le « complément de police » du (vrai) powerline (https://powerline.readthedocs.org/en/latest/installation/linux.html#font-installation) pour avoir les fameux caractères en forme de flèche.

Je n'ai pas cherché plus loin, mais en utilisant scp ainsi, je n'ai pas de barre d'avancement. L'astuce (foireuse, donc) souvent évoquée consiste bien à faire une copie au travers de sshd sur le localhost (pour avoir la barre d'avancement).

Le Powerline dont tu donnes le lien dans ton journal, c'est bien plus qu'une police complémentaire ! C'est un bidule en Python qui fait, entre autres, ce que je liste dans mon précédent commentaire (et on en a un extrait dans ton animation).

Par contre, du coup, je comprends à l’instant que toi, tu utilises ce projet exclusivement pour avoir ces caractères supplémentaires, c’est là que je me suis gouré.

Désolé de la confusion.

Ne t’excuse pas trop vite, parce que perso, je viens de découvrir Powerline grâce à toi, et ça me plaît beaucoup (tout du moins pour sa partie Shell).

Je suis en train de tester tout ça (installation du bousin + des polices sans problème particulier) et je déborde déjà de questions, du genre :

• Comment fait-on une installation pour l'ensemble du système ?
• Existe-t-il une liste des trucs qu'il fait ? (utilisateur courant, SSH, code de retour de la dernière commande, et puis quoi d'autre ?)

’Fin bref, si tu as des liens et/ou des infos, « ça m'intéresse aussi ».

Attention, le premier lien de la dépêche est faux. (mélange avec kernel.org).

C'est pas mal du tout ça ! Ils ont de petits routeurs à des prix très raisonnables (dont 5 ports Giga pour moins de 55 euros !)

Merci beaucoup pour cette référence.

Dans les entêtes retournées par leurs serveurs, on croise l’acronyme "GWS", pour Google Web Server.

... il semblerait en effet que ce soit une modification spécifique de Fedora, depuis la F13 :

Les dépendances doivent maintenant êtres explicites à l'éditions des liens. C'est certes plus propre, mais j'ai tendance à trouver dommage le fait que ça casse la compatibilité.

Pour le coup, ça me semble plus être une conséquence qu'une cause.

... hmmm ?

L'annonce de ce nouveau firmware est intéressante, quand on se souvient des promesses lors de l'annonce du non support de OtherOS sur les PS3 Slim :
http://lists.ozlabs.org/pipermail/cbe-oss-dev/2010-February/(...)

Le bug dont tu parles en fin de message est corrigé (rev 420). Merci de la remontée !

Merci ... Et bien dans ce cas, la backtrace (avec GDB par exemple) va peut être nous en apprendre plus. ("gdb ./mania_drive.static" -> "run" -> crash -> "bt")

Comme beaucoup d'applis 3D, Raydium évite les échanges CPU-GPU (99% des textures sont chargées avant la course, utilisation de "display lists" (modèles 3D déjà dans la carte 3D), etc. Reste donc quasi-exclusivement les calculs CPU, et en particulier la physique (400 Hz avec Raydium, pour éviter les effets tunnel même en flottants simples) qui demande une charge très variable (en fonctions du nombres de contacts, des caches d'OPCODE, ...). De plus, il est probable que 60 FPS soit une limite de ton "écran", ce qui accentue l'effet de saccades.

Cependant, si l'effet est très marqué, il y a peut être un autre problème (Pilote proprio ? Raydium ? ManiaDrive ? ...). Sans "voir" en détail, c'est très dur à dire.

Regarde dans la console, au début en particulier, si le contexte de rendu est indirect (signe que tu n'a pas d'accélération 3D disponible). Je ne sais pas s'il existe des moyens pour les application de détecter Xgl, Compiz et autres et de les contourner. Si quelqu'un a des infos là dessus ...

Non, dans l'esprit de GLUT, Raydium (le moteur "sous" le jeu) utilise systématiquement la résolution du bureau en plein écran.. Il est possible que ça évolue, mais pour l'heure ce comportement nous évite bien des problèmes de compatibilité.

Pour les problèmes de FPS, ton CPU semble effectivement un tout petit peu juste. Essaye en décochant les ombres et avec le volume musique à 0 pour tester l'impact de ces réglages.

Je n'ai pas les moyens de t'aider pour les problèmes de PIC n'ayant pas d'accès au matos concerné. Quelques tests avaient déjà été lancés sur ce sujet dans le forum, peut-être y trouvera-tu de l'aide.

En revanche, je suis désolé pour tes yeux car les liens ne pointent sur aucun serveur en particulier. Va voir sur la page des téléchargements du projet sur SourceForge pour t'en convaincre.