Re: [vhffs] Petit patch pour VhffsFSSYNC (1631)

[Laurent Ducassou <laurent@xxxxxxxxxxxxxx>]

Le 25/10/2010 16:20, Sylvain Rochet a écrit :
> Yop,
>
>
> On Mon, Oct 25, 2010 at 10:08:59AM +0200, Laurent Ducassou wrote:
>> Bonjour,
>>
>> En testant VhffsFSSYNC, j'ai rencontré un comportement très bizarre...
>> (les affirmations ci-dessous sont confirmés par le mode Debug)
>>
>> Si je monitor le dossier /data/web (la racine), alors :
>> - Tous les fichier, dossier et sous dossier, créer avant le démarrage du
>> daemon master sont propagé au slave (uniquement) au démarrage de celui-ci.
> Oui, via le mécanisme de "fullview" en unicast, qui permet au slave de 
> récupérer les morceaux qu'il aurait zappé.
>
>
Pas de problème là.

>> - Tous fichier (ou dossier et sous dossier) crées à la racine PENDANT
>> l'exécution du daemon master sont copiés sur le slave.
> Ainsi que le reste, si tout va bien :-)
Là est le problème...

>> - Aucun fichier (ou dossier et sous dossier) crées dans un sous
>> répertoire de la racine PENDANT l'exécution du daemon ET qui existé au
>> moment du démarrage du daemon master n'est propagé au slave.
> Le master n'écoute pas tant qu'il n'a pas parcouru l'arbre. Quand le 
> slave se connecte/reconnecte il demande une fullview et reçoit dès à 
> présent les changements en cours.
>
> Pas de risque que le master balance une fullview au slave alors qu'il 
> n'a pas tout watché et qu'il zappe des trucs.
>
> 0. Le slave reçoit le contenu de toto/titi/
> 1. Le contenu de toto/titi/ est modifié
> 2. Le master watch toto/titi/
>
> ==> 2. perdu
>
> ==> Il faut donc tout watcher avant que les slave se connectent
>
Hmm, ok !

>> Un bug étrange qui m'a fait fouiner le code C du daemon master malgré la
>> longue époque qui me sépare de mon dernier programme en C. Il en
>> retourne qu'il manque une petite ligne pour permettre de syncroniser les
>> sous-répertoire qui existé déjà au lancement du daemon.
>>
>> Le patch ci-joint corrige ce problème (enfin pour moi). Je peux
>> maintenant créer des fichier sur mes sous dossier et ils sont
>> automatiquement répercuté.
> J'en doute, le patch ne fait juste rien car à ce moment il n'y a pas de 
> slave de connecté sur le mastr.
>
> Es-tu sûr d'avoir attendu que le master écoute sur son port ?
Oui  netstats me le dit :)
> Le vhffsfssync_fake_events_recursively() est là pour corriger un 
> problème de synchronisation qui arrive sur les nouveaux répertoires:
>
> 0. le répertoire titi est créé
> 1. le contenu de ce répertoire est modifié
> 2. le répertoire est watché
>
Il faudrait alors watcher les sous repertoires aussi, non ?
> Le délai entre 0 et 2 est le délai de réception et de traitement d'une 
> notification inotify de nouveau répertoire.
>
> C'est récursif pour un cas particulier:
>
> 0. le répertoire titi est créé
> 1. le répertoire titi/toto est créé
> 2. le répertoire titi est watché
>
>
> Rien à voir avec la récursion initiale.


Au final, hélas, tout marche pas normalement...

Je vais te donner un retour de mes test à l'origine.

J'exécute dans un premier temps sur le master (sans slave) :
- /etc/vhffs/vhffsfssync_master --foreground
--pidfile=/var/run/vhffsfssync_master-data-iso-BSD.pid --port=5678
/data/web"
- Netstat m'indique que le master écoute sur le port 5678 ! Donc c'est bon !

Retour d'exécution :
Monitoring /data/web
t+ .
a+ 1 .
Ready

Puis je lance sur le slave (ou le repertoire /data/web/ est vide...)
- /etc/vhffs/vhffsfssync_slave --foreground --preserve
--pidfile=/var/run/vhffsfssync_slave-data.pid 10.10.0.1:5678 /data/web

Retour d'exécution sur le master :

hello
time
fulltree
get ./b5
get ./b5/ca
get ./b5/ca/59
get ./b5/ca/59/test.com
get ./b5/ca/59/test.com/tmp
get ./b5/ca/59/test.com/php-include
get ./b5/ca/59/test.com/htdocs
get ./b5/ca/59/test.com/htdocs/index.php
get ./b5/ca/59/test.com/htdocs/info.php

  Les fichiers sont maintenant présent sur le slave !
- Maintenant on va tester d'écrire sur le master : vhffs1:/data/web#
mkdir test/
Retour de vhffssync :
wd=1 mask=40000100 cookie=0 len=16 name=test
IN_CREATE
==> MKDIR ./test
t+ ./test
a+ 2 ./test

- Puis un touch sur ce nouveau répertoire : vhffs1:/data/web# touch test/o
Retour :
wd=1 mask=100 cookie=0 len=16 name=o
IN_CREATE
==> CREATE ./o
wd=1 mask=4 cookie=0 len=16 name=o
IN_ATTRIB
wd=1 mask=8 cookie=0 len=16 name=o
IN_CLOSE_WRITE
==> SEND ./o


Bon, on est d'accord, ca marche sur la racine et est effectivement
transmit au slave!

- Tentons un mkdir et touch dans le dossier /data/web/b5/ qui existé
déjà avant le lancement de vhffsfssync_master (et qui à était transmit
au slave par unicast!) :
-- vhffs1:/data/web# mkdir b5/test
-- vhffs1:/data/web# touch b5/o
Retour :
Aucun, le debug du master reste vierge... et si j'écris un fichier dans
/data/web, ça marche. Donc pas un problème de réseau. Plutôt sur la prog?

Si tu as une idée... Personnellement, je sèche là :/

Cordialement,

-- 
Ducassou Laurent

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature