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