Merci pour ces réponses très détaillées ;)<br><br>Et bientôt je me poserai sans doute aussi la question pour Linux.<br><br>Romain<br><br><div class="gmail_quote">Le 5 février 2013 00:28, Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span> a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Il me semblait avoir vu qu'on pouvait indiquer à Windows de ne PAS<br>
maintenir le tri de l'index d'un répertoire particulier (comme il le<br>
fait par défaut), en y mettant un attribut particulier (dans ce cas,<br>
l'index devient une simple liste à parcourir du début à la fin). Pour<br>
des répertoires qui ont de très nombreux fichiers mis à jour très<br>
souvent, ce tri est plus coûteux qu'utile. Mais je ne retrouve plus<br>
l'API sur MSDN.<br>
Malgré tout, si un dossier n'est pas trié, il se pose le problème du<br>
temps de parcours en entier du répertoire avant d'y créer une nouvelle<br>
entrée (sinon il y aurait création d'un doublon), ou pour y retrouver<br>
rapidement un fichier par son nom (c'est ce que fait JTiles puisque'il<br>
n'organise pas du tout ce dossier où il stocke dans un unique dossier<br>
pour chaque fournisseur TMS toutes les tuiles de tous les niveaux de<br>
zoom et de n'importe quelle valeur de x et y).<br>
Comme JTiles est incapable de faire le ménage (il doit y avoir eu du<br>
code pour ça, mais visiblement il ne marche plus ou n'est plus<br>
activé), la seule façon de faire cela efficacement serait que JTiles<br>
divise son cache en sous-dossiers de sorte qu'il n'y ait jamais plus<br>
d'environ 2000 fichiers par sous-dossier. Comment faire ? Déjà il<br>
pourrait créer un niveau de dossier pour le niveau de zoom.<br>
Supposons la limite à entrées par dossier : le niveau de zoom 5 tient<br>
en entier dedans pour toute la planète (je suppose que les tags s'il y<br>
en a sont comptés à part, ils peuvent être aussi stockés à part dans<br>
un unique fichier index "tags"), et les niveaux 0 à 4 tiennent aussi<br>
dans cette limite. Pour le niveau 6 il faudra 4 sous-dossiers, mais le<br>
nombre de sous-dossiers va être multiplié par 4 à chaque niveau de<br>
zoom suivant. On tient jusqu'au niveau de zoom 10.<br>
Après il faudra augmenter la hiérarchie avec un autre niveau de<br>
sous-dossier jusqu'au niveau de zoom 15.<br>
Mais à la longue on a alors plein de niveaux de sous-dossiers, plus ou<br>
moins pleins, et toujours rien pour faire le ménage.<br>
<br>
La solution est alors de stocker toujours 2048 entrées par dossier<br>
mais stocker tous les dossiers à plat en nombre fini (par exemple 256<br>
sous-dossiers (ce qui fera tout de même 512 000 fichiers, on a de la<br>
marge pour un cache confortable !). Pour savoir dans quel sous-dossier<br>
stocker ou trouver un fichier, un simple hachage de son nom suffit !<br>
<br>
A la suite de quoi tous les dossiers ont une taille raisonnable, ils<br>
sont maintenus très rapidement, on peut les lister de façon répétée de<br>
façon exhaustive pour y faire le ménage. Le cache peut alors se<br>
nettoyer tout seul pour respecter les contraintes de taille totale ou<br>
purger les fichiers obsolètes (les fichiers tags sont remplacés par un<br>
fichier index unique stockant les métadonnées HTTP, pas seulement les<br>
ETag, mais aussi les dates d'obsolescence si nécessaire, bien qu(on<br>
puisse aussi décider de rendre tous les fichiers obsolètes une semaine<br>
après leur création, à moins qu'on les "touche" pour les garder en<br>
faisant des requêtes HEAD au serveur)<br>
<br>
Note: sous NTFS un dossier de 2048 entrées prend 512Ko d'index dans la<br>
MFT, non compris les attributs longs ou les données de fichiers courts<br>
comme les Etags justement qui sont aussi stockés directement dans la<br>
même entrée de la MFT sans espace externe supplémentaire). S'y ajoute<br>
pour ce dossier un index de tri (sous-forme de B-arbre) qui prend en<br>
gros 128Ko (et permet des accès directs rapides à un fichier par son<br>
nom). Les suppressions ou ajouts dans un tel dossier ne demandent que<br>
peu d'I/O et pas trop d'opération en mémoire. En revanche pour un<br>
dossier de plus de 60000 entrées (fois 2 avec les fichiers Etag), cela<br>
commence à swapper énormément en mémoire et sollicite beaucoup trop<br>
les caches disques, à cause des opérations de maintenance du B-arbre<br>
(pour maintenir ses critères d'équilibre).<br>
<br>
Le 4 février 2013 23:45, Vincent de Chateau-Thierry <<a href="mailto:vdct@laposte.net">vdct@laposte.net</a>> a écrit :<br>
<div class="HOEnZb"><div class="h5">><br>
> Le 04/02/2013 23:37, Philippe Verdy a écrit :<br>
><br>
>> Merci mais je connaissais déjà la solution<br>
><br>
><br>
> C'est bien à ton mail que je répondais, mais c'était surtout une réponse à<br>
> la question de Romain.<br>
><br>
><br>
> vincent<br>
><br>
> _______________________________________________<br>
> Talk-fr mailing list<br>
> <a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
> <a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
<br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">http://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br>