[Traduction] Stockage unifié : l’explication de texte de Marc de Courville, CTO d’Archos

samedi 7/03/2015 par


Retour sur la fonction de stockage unifié, évoquée lors de l’annonce de la gamme Magnus.

Ce système, appelé Archos Fusion Storage permet de combiner de manière transparente pour l’utilisateur la mémoire des cartes micro-SD additionnelles avec la mémoire interne des produits Archos.
L’objectif ? Pouvoir allouer plus d’espace pour les applications, les jeux et le multimédia d’une manière générale : à chaque fois que votre mémoire interne est pleine, ce système migrera automatiquement et intelligemment les données, optimisant l’équilibrage de la mémoire, dispatchant et organisant les fichiers extra-larges de manière à ce que l’utilisateur n’ait plus à s’en soucier lui-même.

Belle théorie... mais dans la pratique ? Marc de Courville, le CTO d’Archos (et donc responsable de la R&D) nous propose des explications techniques complémentaires (dans la langue de Shakespeare - traduction plus bas les moins anglophones d’entre vous).

Archos Fusion Storage consists in a user friendly expansion of Android phone/tablet storage space proposed at external SDcard insertion featuring :
- transparent fusion of internal storage and external sdcard : you can do it anytime and seamlessly (as opposed to hard internal storage/external SDcard switch)
- optimization of data/media and application storage : a migration process of internal data to external storage is proposed
- no file size limit even with FAT32 sdcard without reformatting : transparent to Android file splitting
- smart storage management, user do not need to keep track of the location of a file : internal/external storage load balancing

Technology under the hood : it relies on fuse kernel module that enables to unify storage at operating system level in order to be transparent to Android framework. Automatic large file split and storage balancing are Archos proprietary extensions to unionfs fuse module.

Et pour les plus technophiles d’entre vous, une description complète du système :

From the user’s point of view, it’s an option to unify external and internal storage.
Here are some explanations of how Android handles storage, and what Archos did to get around Android’s limits.

To fully grasp the concept you need to know the 4 essential folders where applications and data get stored in Android :
- /data/app : this is where the application apk goes. Once the apk is installed, this part never changes ;
- /data/data : this is where the application stores settings and cache, some optimizations (odexes) done by Android at the installation.
Some games (or applications) even store uncompressed data here.
Often /data/data for an application is larger than the /data/app space itself (e.g. mail apps)
Implicitly /data/data refers to the total size excluding the apk of the app (i.e. the sum of /data/data, /data/dalvik-cache, /data/app-lib/ and many other folders size)
- /sdcard which is a "shared storage among many applications" zone ;
- /extsdcard - the physical external sdcard file system (note that this name may change depending on the manufacturer’s implementation).

Historically, only /data (so /data/app/ and /data/data/) existed. Apps were isolated and no file sharing between them was (easily) possible.
Then along came Camera applications that needed to share pictures across many applications. The solution was a shared storage space expandable in size through the use of a uSD : the traditional /sdcard zone !
This uSD used a FAT file system, which inherently could not handle file permissions and thus allowed cross application file sharing.
This shared folder was thus called /sdcard (or ExternalStorage from Android API ) and this name is still there nowadays on Android to preserve legacy compatibility.
Surprisingly, some recent devices such as the Android One still require a physical uSD card to take camera pictures (like the old G1).

At one point internal storage space was not big enough to install loads of heavy applications and Google introduced the App2SD feature in Android Froyo allowing users move /data/app to /sdcard.
Note that /data/data was not moved but in most cases contains the larger part of an applications storage use...

Thus some heavy games started to be split in two parts : the APK itself, and the game data (e.g. textures, maps, etc).
Usually the APK downloads the data by itself, and put the result in the sdcard so that user can install more games.

Then, some manufacturers wanted to be able to take photos/save videos without adding a uSD, so they added a partition to the internal storage (eMMC or NAND flash) which behaved like a sdcard.
Since all applications were expecting the sdcard to be in /sdcard, this new internal partition has been mounted on /sdcard as well.
From this moment /sdcard stopped referring to an existing external, physical uSD creating a little (read : a lot) of confusion for end users.
App2SD in this case was only used to move an apk between two partitions of the same physical internal storage. Which is not really that much help.

The main issue with this approach is that the partition is fixed in size during the production process providing no flexibility in the balance between storage allocated to applications or multimedia files.
To get around this hard partion split, when Android 3.0 "Honeycomb" came around Google created a virtual filesystem called "sdcard" which fakes the same permission behavior as a standard FAT uSD, and in reality stores the multimedia files in /data/media (so in the /data partition). Though software shielded, the two legacy storage spaces are residing on the same physical partition.
At this point, a fuse daemon called sdcard is present with the unique aim of emulating the legacy /sdcard and the external ExternalStorage variable refers to an internal storage... Which isn’t confusing at all.

After that change, in Jellybean, Google started to implement the multi-user system on Android. One thing that appeared, is that games on multiple accounts would be downloaded multiple times.
In order to overcome this problem, games were recommended to move their data to /sdcard/Android/obb, because this folder could be shared among all the device users.

Before Kitkat, there was simply no official way for an application to know if a second shared storage was available (either an actual uSD, USB storage, etc.).
Some applications (mostly File Managers, or downloaders) manage to handle secondary storage using non-standard ways.
Very few applications have started to use the new Android 4.4 API to handle secondary storage (only Google Music is a big one that actually does it).

So, basically, most applications are still storing their data in /sdcard blindly.

After this short introduction into the wonderful (and not at all confusing) world of storage on Android here comes the changes Archos that made !
The user now has the possibility to have /sdcard being a virtual filesystem, which consists in a fusion of /data/media (as previous sdcard emulation) and the external sdcard.

This is made possible by a fuse FS. It is a fork of unionfs-fuse, a fuse meant to have a virtual filesystem which merges one writable file system, and one which is read-only.
The source filesystems are called branches. The first branch is the external sdcard, the second branch is /data/media.
Here are the features of this unionfs fork :
- No file permissions implemented, to behave as a FAT. The fuse FS is still backed by the original android "sdcard" daemon to handle permissions properly.
- The files can be written on any branch. If a file already exists on one of the branch, it uses this branch.
- The branch used for new files is the external sdcard, unless it has less than 2GB available, in which case it goes to the storage.
- The files are automatically split at 2GB directly on write/read calls.

To be able to use this fuse FS, some other modifications were required :
- There is an init script, which on boots, determines if the current uSD is the same as the previous boot.
If it is different, it disables the fusion, and asks the user if he wants to activate it.
- There is another init script, which checks if the fusion is enabled, and if it is enabled the unionfs is activated with the sdcard daemon on top of it.
If it is disabled, the sdcard daemon is just started with standard /data/media
The intermediate mountpoints (/sd/external for the sdcard, and /sd/emulated for the unionfs) are located in /sd, which is accessible only by media_rw:media_rw, thus only system apps can access it.

This fusion only requires a reboot to be activated. At this point, old files still remain on the internal storage, and new files are created on the sdcard.
So there is another optional step available to optimize the storage space for applications, which consists in migrating the files from /data/media to the /sd/external.
There is no cache in the fuse FS thus we can move files on the fly without any specific safe guards.

By the way, Android API mentions that /sdcard should be considered as a non-safe storage, so all problems like files disappearing because the sdcard has been removed should already be handled by the applications.
Indeed, one can notice that most applications downloads again their data when detecting that they are missing providing inherently a cold sdcard removal resilience.

Traduction des explications de Marc de Courville

Cette traduction est donnée à titre informatif et peut être inexacte.

L’Archos fusion storage est une extension pour Android (tablettes et téléphones) permettant d’ajouter des fonctionnalités à l’insertion d’une carte SD :

  • Fusion du stockage interne avec le stockage externe de la carte SD en toute transparence : Vous pouvez le faire à tout moment et sans redémarrer le téléphone.
  • Optimisation de data/media et du stockage des application : un processus de migration des données contenues sur le stockage interne vers le stockage externe est proposé.
  • Plus de taille limite de fichier y compris avec un formatage en FAT32 (+- 4 Go max) : Les fichiers sont automatiquement découpés.
  • Gestion du stockage intelligente, l’utilisateur n’a plus besoin de connaître l’emplacement des fichiers : les stockages internes et externes sont utilisés tous les deux et font l’objet d’une gestion de charge.

Avant-gout sur la technique utilisée : Tout repose sur le module fuse du noyau qui permet d’unifier le stockage au niveau de l’OS, en toute transparence pour Android. Les technologies de découpage automatique de fichiers et de répartition du stockage sont des extensions propriétaires d’Archos au module unionfs de fuse.
Du point de vue de l’utilisateur, il s’agit d’une option pour unifier les stockages internes et externes.
Voici quelques explications sur le fonctionnement d’Android, sa manière de gérer le stockage et des méthodes utilisées par Archos pour contourner les limites d’Android.

Pour totalement comprendre le concept, il est nécessaire de connaître les 4 princpaux dossiers dans lesquels les applications et les données sont stockés dans Android :

  • /data/app : c’est là que sont stockés les .apk des applications. Une fois l’apk installé, plus rien ne change ici.
  • /data/data : c’est là que l’application stocke ses paramètres et son cache. Des optimisations (indexation) sont réalisées par Android à l’installation. Certains jeux (et applications) stockent également des données décompressées ici. Bien souvent le dossier /data/data d’une application est plus gros que le dossier /data/app lui-même (par exemple pour les applications d’email). Implicitement /data/data fait référence à la taille totale de l’application en excluant le dossier /data/app. (En gros la somme des tailles de /data/data, /data/dalvik-cache, /data/app-lib et d’autres dossiers).
  • /sdcard qui est une zone de stockage partagée par les applications
  • /extsdcard qui est le point de montage de la carte SD (il est possible que le nom change, chaque constructeurs l’implémente comme il le souhaite).
    Historiquement, seul /data (donc /data/app/ et /data/data/) existait. Les applications étaient isolées et aucun fichier n’était partagé (facilement) entre elles.

Et puis est arrivée l’application Appareil photo qui avait besoin de partager des photos avec beaucoup d’applications. La solution était de créer un espace de stockage partagée et extensible en taille au travers d’une carte SD : /sdcard !

Cette microSD utilisait un système de fichiers en FAT, ce qui ne permettait pas de gérer les permissions de fichiers et ainsi autorisait le partage de fichiers par les applications.

Ce dossier partagé s’est appelé /sdcard (ExternalStorage dans l’API Android) et ce nom est conservé de nos jours pour permettre de conserver la compatibilité.

Étonnamment, des appareils réçents comme l’Android One ont toujours besoin d’une carte SD physique pour prendre des photos (comme le vieux G1).

A un moment, le stockage interne est devenu insuffisant pour stocker un grand nombre d’applications lourdes et Google a introduit App2SD dans la version Froyo d’Android. Cette fonctionnalité autorise les utilisateurs à déplacer le dossier /data/app sur /sdcard.

Notez que /data/data n’était pas déplacé mais que dans la majorité des cas, il contenait les fichier les plus volumineux de l’application.
De ce fait, certains gros jeux ont commencé à se découper en deux parties : l’apk lui même, et les données du jeu (textures, cartes etc.)
Généralement, l’APK télécharge lui-même les données et les placent dans /sdcard et l’utilisateur peut ainsi installer d’autres jeux.

Et puis, les constructeurs ont voulu pouvoir prendre des photos/enregistrer des vidés sans ajouter une microSD, donc ils ont ajoutés une partition dans le stockage interne qui aurait le comportement d’une carte SD.
Et comme les applications s’attendaient à trouver une carte SD sur /sdcard, cette nouvelle partition interne a été montée sur /sdcard.
A partir de ce moment, /sdcard a cessé de se référer à une carte SD physique ce qui a créé une petite ( énorme en fait) confusion pour les utilisateurs finaux.
App2SD, dans ce cas, se contentait de déplacer un apk entre deux partitions du même stockage physique ce qui n’aidait en rien.
Le principal problème avec cette approche est que la taille de la partition est fixée durant le processus de fabrication ce qui ne permet aucune flexibilité dans la proportion de stockage allouée aux applications ou au fichiers multimédia.

Pour se débarrasser de ce problème de partition découpée en dur, quand Android 3.0 « HoneyComb » est sorti, Google a créé un système de fichiers virtuel nommé « sdcard » qui imite le même système de permission qu’une carte SD standard en FAT, mais qui stocke en réalité les fichiers multimédias dans /data/media (donc la partition /data).

Bien que le système soit blindé, les deux espaces de stockages sont sur la même partition physique.

A ce moment, un daemon fuse nommé sdcard est présent dans l’unique objectif d’émuler le stockage /sdcard existant et l’objet ExternalStorage fait référence à un stockage interne... Ce qui ne porte pas du tout à confusion.

Après ce changement, dans JellyBean, Google a commencé à implémenter le système de multi-utilisateurs dans Android. Il est apparu que le même jeu, sur différents comptes serait téléchargés à plusieurs reprises.

Pour contourner le problème, les jeux avaient pour recommandation de déplacer leurs données sur /sdcard/Android/obb parce que ce dossier pouvait être partagé entre tous les utilisateurs.

Avant Kitkat, il n’y avait officiellement aucun moyen simple pour une application de savoir si un espace de stockage partagé existait. (Une carte SD, une clé USB etc.)
Quelques applications comme FileManager ou des Download arrivent à gérer un deuxième stockage en utilisant des méthodes non conventionnelles.
Un nombre restreint d’applications ont commencé à utiliser la nouvelle API pour gérer un espace de stockage secondaire (Google Music est l’une des seules grosses applications à le faire).

Donc basiquement, la plupart des applications continuent à stocker leur données dans /sdcard, à l’aveugle.

Après cette « petite » introduction dans le monde merveilleux ( et pas confus du tout) du stockage sur Android, voici les changements qu’Archos a réalisé !

L’utilisateur a désormais la possibilité d’avoir /sdcard comme étant la fusion de /data/media et de la carte SD externe.

Ce changement a été possible grâce à fuse FS. Il s’agit d’un fork (un projet émanent d’un autre) de unionfs-fuse, un fuse est un système de fichier virtuel qui fusionne système de fichiers accessible en écriture avec un système en lecture seule.
Les systèmes de fichiers sources sont nommés branches. La première branche est le système de carte SD externe. La seconde est /data/media.

Voici les fonctionnalités de ce fork d’unionfs :

  • les permissions des fichiers ne sont pas implémentées pour se comporter comme sur du FAT. Fuse FS se base toujours sur le daemon sdcard pour gérer les permissions correctement.
  • Les fichiers peuvent être écrits sur n’importe qu’elle branche. Si un fichier existe sur une des branches, il utilise cette branche.
  • La branche utilisée pour les nouveaux fichiers est la carte sd externe, sauf si elle a moins de 2Go disponible, auquel cas on écrit sur le stockage interne.
  • Les fichiers sont découpés directement en bloc de 2Go lors des appels système de lecture/écriture

Pour permettre d’utilise ce fuseFS, d’autres modifications étaient nécessaires :
Il existe un script d’initialisation, qui au démarrage détermine si la carte SD est la même qu’au dernier démarrage. Si ce n’est pas le cas, il désactive la fusion et demande à l’utilisateur si il souhaite l’activer.

Un autre script d’initialisation vérifie si la fusion est activée et active unionfs avec le daemon sdcard le cas échéant. Sinon, il active le daemon sdcard avec le /data/media standard.

Les points de montages intermédiaires tels que /sd/external pour la carte sd et /sd/emulated pour l’unionFS sont situés dans /sd qui est accessible uniquement par l’utilisateur media_rw du groupe media_rw donc seule les apps systèmes peuvent y accéder.

La fusion nécessite un redémarrage pour être activée. A ce moment, les anciens fichiers restent sur le stockage interne et les nouveaux sont créés sur la carte SD.

Donc il existe une étape optionnelle pour optimiser l’espace de stockage pour les applications qui consiste à migrer les fichiers d e/data/media vers /sd/external.
Il n’y a pas de cache dans fuse FS donc on déplace les fichiers à la volée sans aucun garde-fou.

De toute manière, l’API Android spécifie que /sdcard doit être considéré comme un espace de stockage non-sûr, donc les problèmes liés à la disparition de fichiers au retrait de la carte SD devraient déjà être gérés par les applications.

De fait, on peut constater que la plupart des applications téléchargent à nouveau leurs données quand elles détectent que des fichiers sont manquants .

Partagez cet article sur les réseaux sociaux: + FB
[ télécharger l'article au format PDF]