[OSM-talk-fr] panne des rendu HOT OpenRiverBoatMap Route500/BDCarthage/QA/FrAdm
Philippe Verdy
verdy_p at wanadoo.fr
Mar 10 Juil 12:29:49 UTC 2018
Le 9 juillet 2018 à 09:20, Christian Quest <cquest at openstreetmap.fr> a
écrit :
> Le rendu Route500 et Hydro (Carthage + BDTopo Hydro) sont de retour.
>
> Manque encore le rendu QA et FRadm + les analyses osmose.
>
> Le 7 juillet 2018 à 16:14, Christian Quest <cquest at openstreetmap.fr> a
> écrit :
>
>> La semaine dernière un des SSD d'osm13 a rendu l'âme après presque 6 ans
>> d'usage intensif.
>>
>> Voilà ce que j'appelle "usage intensif":
>> - plus de 47000 heures de vol
>>
> Les SSD actuels sont en centaines de milliers d'heure.
> - plus de 100To écrits (soit 200 fois la capacité du SSD de 480Go)
>>
> 200 fois c'est peu, les SSD actuels promettent plusieurs milliers de
réécriture par secteur. De plus ils compensent des pannes éventuelles sur
certains secteurs avec une réserve supplémentaire en faisant cycler (cela
évite les cas pathologiques lors que le SSD est presque plein, où quelques
secteurs seulement sont constamment réécrits et les autres beaucoup moins
souvent. La ressource critique est la mémoire de "tags" qui permet de
mapper les secteurs logiques en secteurs physiques (dont la position change
constamment à chaque écriture en les réallouant parmi les secteurs trimmés,
qui eux aussi doivent avoir une réserve suffisante pour ne pas tourner sur
le même petit nombre: au besoin le firmware SSD devrait aussi recycler les
secteurs logiques non réécrits mais sur des secteurs beaucoup moins souvent
écrits afin de les mettre sur des secteurs trimmés trop fréquemment
réécrits mais encore fiables; chaque trim d'un secteur devrait tenir un
compteur pour déterminer ce qu'il faudrait déplacer afin de préserver le
reste en distribuant la charge sur la totalité du disque; la réserve libre
non allouable devrait être de l'ordre de 10% de la capacité physique pour
avoir 90% de capacité logique; la petite mémoire de tags devrait être
constituée de mémoire nettement plus fiable et plus rapide, sa capacité
réduite permet de la maintenir en RAM volatile synchronisée prioritairement
vers la mémoire flash, avec une réserve d'énergie suffisante et pour cela
le firmware devrait maintenir un pool minimum de pages prétrimmés libres
pour sauvegarder très facilement et rapidement la mémoire de tags sans
avoir besoin de beaucoup d'énergie).
Cependant des lecteurs SSD bon marché n'ont même pas de réserve d'énergie
suffisante ou c'est un simple condensateur électrolytique dont la duré de
vie est limitée et trop utilisé en pleine capacité de charge avec une
"mémoire de charge" qui se dégrade comme les batteries de smartphones avec
un hystérésis important. Certains qui n'ont aucune réserve d'énergie ont
simplement alloué la mémoire de tags dans un petit journal cyclique sur des
pages qui s'usent prématurément plus vites que le reste de la capacité de
stockage logique et physique, et avec un trop petit pool de pages trimmées
libre pour ce journal: ils sont faits comme les clés USB, qui peuvent se
bloquer en lecture seul très vite (j'ai eu une clé USB3, pourtant de marque
Philips, qui n'a pas tenu son premier formatage pour y installer une image
ISO bootable de Windows, la copie s'est bloquée au milieu, la clé est
passée en lecture seule définitive avec moins de 300 méga écrits dessus sur
une clé de 32 Go!).
OCZ (comme les fabricants de clés de stockage USB) n'est pas réputé pour la
fiabilité de ses SSD et notamment de son firmware trop simpliste assurant
un recyclage statistiquement correct des pages de stockage. Sur un SSD
c'est toujours la mémoire de tags qui est la plus sollicitée, elle doit
avoir des tampons maintenant sa durabilité et le meilleur moyen reste d'y
inclure un cache en registres CMOS et un cache de second niveau en DRAM,
une réserve d'énergie, avant la couche finale flash, et une bonne gestion
des priorités internes dans les bus internes.
- plus de 11100 To de lus, 1.1 Po
Là oui c'est intensif, mais normalement pas un problème pour les SSD, la
lecture ne touchant ni à la mémoire de tags, ni ne nécessitant aucune
opération de trim et recyclage.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20180710/c5a26809/attachment.htm>
Plus d'informations sur la liste de diffusion Talk-fr