Longevity de lecteur flash dans l'iPhone

Question

du guide de programmation iPhone

Lors de la création de fichiers ou d'écrire des données de fichiers, garder les directives suivantes à l'esprit:

1. Réduire la quantité de données que vous écrire sur le disque. Les opérations sur les fichiers sont relativement lentes et impliquent l'écriture sur le disque Flash, qui a une durée de vie limitée. Voici quelques conseils spécifiques pour vous aider à minimiser les opérations liées aux fichiers:
   1. Ecrivez uniquement les parties du fichier modifiées, mais regroupez les modifications lorsque vous le pouvez.
   2. Évitez d'écrire le fichier entier juste pour changer quelques octets.
   3. Lors de la définition de votre format de fichier, regroupez le contenu fréquemment modifié afin de minimiser le nombre global de blocs devant être écrits sur le disque à chaque fois.
   4. Si vos données sont constituées de contenu structuré accédé de manière aléatoire, stockez-le dans un magasin persistant Core Data ou dans une base de données SQLite. Ceci est particulièrement important si la quantité de données que vous manipulez peut atteindre plus de quelques mégaoctets.
2. Évitez d'écrire des fichiers de cache sur le disque. La seule exception à cette règle est lorsque votre application se ferme et que vous devez écrire des informations d'état qui peuvent être utilisées pour remettre votre application dans le même état lors du prochain lancement.

Je lis un article tout à l'heure en ce qui concerne les disques SSD intel (que je ne peux pas trouver en ce moment, malheureusement), qui a mentionné que la principale préoccupation de la longévité est due au fait que le système d'exploitation n'a pas supprimé réellement données, mais juste des blocs marqués comme libres, provoquant un ralentissement plutôt douloureux lorsque ces blocs «libres» étaient écrits (causant un read-modify-store, plutôt qu'un simple stockage). Cela s'applique-t-il également à l'iPhone, c'est-à-dire que le lecteur sera plus sensible aux ralentissements lorsque les fichiers sont supprimés plus fréquemment?

Je considère un format de fichier basé sur un redo-log, de cette façon je peux maintenir une annulation inter-session et je n'ai pas non plus d'écritures aléatoires (toujours ajouter), mais à un moment je suppose que j'aurai consolider au moins une partie du journal, pour maintenir la taille du fichier à un niveau raisonnable. Ma question dans ce cas, qui serait plus efficace (en termes de longévité)? J'ai deux ou trois chemins que j'ai considéré

1. Ecraser le même fichier et
   1. tronquer l'espace que je ne ai pas besoin
   2. ou laisser cet espace (rempli de données anciennes) et le remplacer quand j'ai besoin encore
2. ou écrire un nouveau fichier, et supprimer l'ancien

mais je suis ouvert aux suggestions. Je suppose que la taille typique d'un fichier va de quelques kB à quelques centaines de ko, mais la valeur la plus élevée est plus spéculative que toute autre chose.

Answer 1

Vous n'avez pas à vous soucier de ce problème particulier.Comme de nombreux appareils intégrés, l'iPhone parle directement aux puces flash, en utilisant une interface similaire à celle utilisée par une puce de contrôleur SSD (quelque chose comme ONFI). Le FTL (couche de traduction instantanée) sur l'iPhone est un logiciel géré par l'OS, qui a une connaissance complète des blocs utilisés. Bien qu'Apple ne documente pas ce comportement, vous pouvez en voir indirectement la preuve dans le code source xnu public qui (depuis un certain temps) a le support dans HFS + pour communiquer à la couche de blocs que des blocs particuliers ne sont plus utile. Aucun périphérique de bloc open source ne fait quoi que ce soit avec cette information, mais si vous prenez un iPhone jailbreaké et que vous démontez son noyau, vous verrez qu'il est utilisé sur l'iPhone.

Évidemment, vous ne devriez pas essayer de dépendre de ce comportement, je dis juste que vous n'avez pas besoin de s'inquiéter, il fait la bonne chose.