Published using Google Docs
L'avenir Des Systèmes De Fichiers (2010)
Updated automatically every 5 minutes

L'avenir des systèmes de fichiers

Les systèmes de fichiers sont en pleine mutation pour répondre aux nouveaux usages. Plusieurs approches sont envisagées, répondant à des besoins spécifiques. Cela aura un impact sur les applications à développer. Regardons les différentes approches et les produits proposés.

Par Philippe PRADOS - 2010
www.prados.fr

Pour livrer des fichiers à des applications, plusieurs niveaux d'abstractions sont possibles. Des systèmes d'ECM proposent d'organiser les fichiers, de gérer leurs cycles de vies ou l'évolution des versions. Par exemple, Alfresco[i] publie des fichiers sous différents protocoles.

Puis viennent les composants s'occupant de publier des fichiers sur le réseau, comme NFS ou SAMBA. Ce sont des NAS.

Viens ensuite les systèmes de fichiers en charge d'organiser le disque dur pour mémoriser les données et les organiser dans des fichiers.

Enfin, intervient les drivers de niveau bloc, en charge d'écrire physiquement sur les disques, morceaux par morceaux.

Dans le cadre de cette article, nous nous intéressons aux gestionnaires de fichiers et aux systèmes de fichiers et leurs relations avec les niveaux inférieurs.

Les gestionnaires de fichiers sont généralement conforme aux spécifications POSIX, définie depuis 1988 par l'IEEE[ii] et formellement désignée par IEEE 1003. Ces standards ont émergé d'un projet de standardisation des API des logiciels destinés à fonctionner sur des variantes du système d'exploitation UNIX. Les spécifications étant payantes et non publiques, le standard Single UNIX Specification[iii] propose une version allégée publique. Les chapitres 2.5 et 2.6 du chapitre "System Interface" traitent spécifiquement des APIs d'accès aux fichiers.

Limitations fonctionnelles

Les systèmes de fichiers contemporains ont plusieurs difficultés

D'où la volonté de revoir les gestionnaires de fichiers pour offrir de meilleures performances, adaptées aux nouveaux besoins.

Principes architecturaux

Les systèmes de fichiers organisent les masses importantes de données disponibles sur les disques physiques, en informations structurées, permettant la lecture et la modification de fichiers dans de bonne condition de performance et d'intégrité.

Deux familles de gestionnaires de fichiers traitent d'architectures différentes. La famille orienté OS permet une gestion des fichiers par le système d'exploitation. La famille orienté Cluster, permet la gestion d'un système de fichiers par différents nœuds d'une grappe de serveur.

Systèmes de gestions de fichiers orientés OS

Les systèmes de gestion de fichiers orientés OS sont en charge de l'organisation des fichiers sur un disque physique. Initialement, cela faisait partie du cœur des systèmes d'exploitation. Depuis de nombreuses années, le système d'exploitation propose une abstraction (VFS) permettant l'intégration de différents gestionnaires de fichiers par ajout de composant logiciel.

Les données et les méta-données sont organisées pour minimiser autant que possible le déplacement de la tête de lecture et limiter le nombre d'accès en lecture et en écriture. Inévitablement, les structures se dégradent, entrainant un besoin de défragmentation des données. De plus, lors d'un dysfonctionnement (coupure électrique, échec de lecture ou d'écriture), il doit être possible de vérifier rapidement le système de fichier pour garantir son intégrité.

Les nouveaux usages des systèmes de fichiers entrainent de nouveaux besoins que les évolutions à venir se proposent de combler:

Intégrité, vérification et réparation plus rapide lors d'un crash

Pour permettre une vérification du système de fichier plus rapide (fsck), les nouvelles structures de données sont moins sensible à un crash. Un fichier de log permet de connaitre les dernières modifications effectués dans le système de gestion de fichier, juste avant le crash. Certain système de fichier sont capable d'effectuer cette vérification pendant le fonctionnement du système, permettant une reprise rapide d'activité. La réparation s'effectuant à chaud.

De plus, chaque bloc de donnée ou de méta-données possède un résultat de calcul de checksum permettant d'identifier plus facilement les erreurs.

Réduction de la fragmentation

Pour réduire la fragmentation des fichiers, plusieurs stratégies se mettent en place. La première consiste à pre-réserver de l'espace sur le disque lors de la création d'un fichier (amélioration de la fonction fallocate() ). Ainsi, un programme qui est capable de prédire une taille prévisible du fichier qu'il souhaite créer, peut demander un espace disque continu plus important. Les données complémentaires ajoutées par la suite seront proches des données initiales. Cela n'est bénéfique que si les applications utilisent cette nouvelle fonctionnalité.

La deuxième approche consiste à retarder la réservation des ressources. La réservation de l'espace sur disque et l'écriture des données sont effectuées plus tard, permettant au système d'avoir une meilleure connaissance du volume de donnée à traiter, et d'allouer ainsi des ressources contigües.

D'autres parts, les petits fichiers peuvent être directement inclus dans les méta-données du gestionnaire de fichier, évitant ainsi la lecture de nouveaux secteurs. Les blocs sont traités par les deux bouts : En tête, les méta-données ; en queues, les données peu volumineuses.

Prise de cliché

Les données étant volatiles sur disque, il est difficile de reconstituer une situation passée. De plus, lors d'un archivage des données, il est préférable d'interrompre tous traitements, afin de garantir la consistance des données sauvegardées. Pour résoudre cela, les nouveaux systèmes de fichiers proposent la prise de cliché du système de fichier. Ainsi, toutes les modifications suivantes n'auront pas d'impact sur le cliché. Il est lors possible d'effectuer un backup, sans interrompre les traitements. Cela peut également être utilisé comme moteur de transaction lors d'une modification. En cas d'échec, le cliché précédant est récupéré.

Pour faire cela, ils proposent la notion de copy-on-write. C'est-à-dire que le cliché est un paramètre qui permet, par la suite, la création d'une copie d'un bloc seulement si celui-ci évolue après la prise d'empreinte.

Les clichés sont parfois également accessibles en écriture, permettant une évolution arborescente des données d'un disque. Il est également possible d'avoir un cliché d'un autre cliché. Cela risque de complexifier la gestion des disques.

Les structures de données nécessaires à ces fonctionnalités permettent également d'avoir plusieurs racines dans le même gestionnaire de fichier. Il s'agit en fait d'un cliché vide depuis la racine. Ainsi, il est plus facile d'isoler des systèmes, sans devoir utiliser plusieurs disques ou plusieurs partitions. Les ressources utilisées sont alors optimum.

Des machines virtuelles peuvent, par exemple, partager le même disque et la même structure, tout en étant isolés l'une de l'autre, ou s'appuyer sur le même OS et avoir des paramètres ou des composants différents dans des clichés spécifiques. Cela contribue à une meilleure exploitation des ressources.

Augmentation dynamique des volumes

Les volumes de données traitées par les entreprises est en inflation constante. Les structures actuelles des gestionnaires de fichiers ne permettent pas l'augmentation des volumes, sans une migration des données. Les nouveaux gestionnaires cherchent à permettre cette évolution à chaud, permettant l'ajout de disques lors du fonctionnement.

Système de gestion de fichier orienté Cluster

Quatre stratégies permettent le partage de fichiers dans un cluster :

Notez que l'utilisation de ces architectures peuvent avoir des influences[iv] sur les bonnes pratiques de développement. Les programmes qui fonctionnent convenablement sur un disque local peuvent présenter des erreurs lors de l'utilisation d'un disque partagé.

Normes et standards

Pour le système Linux, les standards de fait consiste à identifier les gestionnaires de fichiers inclus dans la branche principale du noyau.

Les acteurs des futurs FS

Les différentes évolutions des gestionnaires de fichiers étaient répartie dans différentes entreprises. Depuis peu, avec le rachat de Sun, Oracle possède un quasi monopole sur les systèmes les plus abouties. Certaines solutions sont propriétaires, d'autres sont libres. Elles recouvrent parfois les mêmes besoins.

Oracle

Depuis le rachat de Sun par Oracle, la stratégie d'Oracle sur les FS n'est pas lisible. OCFS n'a vocation qu'a répondre aux spécificités des bases de donnée de l'éditeur.

Red hat

Red-Hat propose un gestionnaire de fichier hautement disponible pour enrichir son offre sur le système d'exploitation. GFS est une brique d'un ensemble plus vaste de technologies.

Open source

Les solutions Open sources répondent aux exigences nouvelles des applications.

Analyse de l'offre

L'offre se divise en deux catégories, suivant si le gestionnaire de fichier est orienté cluster ou OS.

Gestionnaires de fichiers orientés cluster

Hadoop FS

Hadoop FS[v] est un gestionnaire de fichiers répartie, sous licence Apache, conçu pour fonctionner sur des hardwares à bas coût. Les principes fondateurs sont les suivants :

Les stratégies de réplications des données sont adaptés suivant la localisation des nœuds dans les racks. Les données sont dupliquées d'abord dans le même rack puis au moins une fois dans un autre rack. Les données sont créées dans un rack identique au rack consommateur de la ressource (affinité d'usage).

Hadoop FS s'appuie sur un autre gestionnaire de fichier orienté OS pour sauver les données dans chaque serveur, à raison d'un fichier par bloc. Chaque disque possède un fragment des données de l'ensemble.

Ce système n'est pas Posix ni intégré au noyau Linux. Il propose des APIs spécifiques.

OCFS

OCFS[vi] d'Oracle est un gestionnaire utilisant le disque pour communiquer entre les nœuds d'une grappe. Comme indiqué par le constructeur, ce gestionnaire de fichier a été conçu pour gérer les fichiers d'une base Oracle, pas pour traiter tous type de fichiers[vii]. Il s'appuie sur un GNBD (Global Network Block Device).

Un mécanisme de verrou global et de verrou local par membre de la grappe est mis en place, par gestion de time-out sur l'évolution de certains secteurs. (La manipulation d'un secteur est considéré comme atomique). Lors du lancement d'un nouveau nœud, ce dernier utilise le verrou global pour obtenir un identifiant de nœud, et bénéficier de secteurs privés pour permettre la communication avec les autres nœuds. Un protocole de vote est également disponible, permettant la synchronisation des nœuds.

Cette implémentation présente la particularité de ne pas dépendre du réseau pour gérer les verrous. Par contre, le nombre de nœuds maximum est un paramètre à indiquer lors du formatage du disque. La découverte et la communication des nœuds utilise l'écriture de secteurs sur disque. Ces derniers sont fortement sollicités et ne doivent pas présenter de défaillances.

OCFS est sous licence GPL.

Google FS

Google FS[viii] propose une approche similaire à Hadoop HS. Un serveur intermédiaire est en charge de la distribution des données. Pour éviter les contentions lors des mises à jours, le système est spécialisé pour permettre facilement l'ajout d'information à un fichier par plusieurs processus. L'ordre des ajouts n'est pas garantie, mais chaque ajout est atomique. Pour gérer les défaillances, les données sont dupliquées au minimum sur trois disques.

GoogleFS s'appuie sur un autre gestionnaire de fichier orienté OS pour sauver un fragment des données dans chaque serveur.

Au niveau architecture, un serveur maintient en mémoire la localisation de tous les blocs (taille de 1Go) sur tous les disques. Les évolutions sont enregistrées dans un log redondé. Des serveurs de données se chargent alors de sauver les blocs sur leurs disques respectifs et de maintenir les caches mémoires. En cas de défaillance d'un disque, toutes les données perdues sont dupliquées dynamiquement à partir des autres disques, vers un nouveau serveur de données.

Des API spécifiques sont nécessaires pour traiter ce gestionnaire de fichier, permettant l'ajout de données à un fichier et d'obtenir en réponse, sa localisation physique par rapport au début du fichier. Ce système n'est pas POSIX ni intégré au noyau Linux.

Gestionnaires de fichiers orientés OS

ext4

Le système de fichier ext, utilisés actuellement sous Linux a été conçu il y plus de quinze ans, en 1992, puis amélioré en 1999 avec ext2 et en 1999 avec ext3 et l'ajout d'un fichier journal.

ext4[ix] a été intégré dans la version 2.6.19 du noyau linux, à titre expérimental. Il est considéré comme stable depuis la version 2.6.28 du noyau.

La structure de donnée est compatible avec la précédente version (ext3), il n'est donc pas nécessaire d'effectuer une migration des données pour l'utiliser. Par contre, la migration est préférable si on souhaite bénéficier des nouvelles optimisations.

Certaines limitations de ext3 sont repoussées comme le nombre de sous-répertoire qui est maintenant illimité.

Un mécanisme d'extend permet d'indiquer qu'un fichier débute par un bloc et continue dans les n blocs suivants. Cela permet de réduire la fragmentation. Ce mécanisme est mis en place lors de la création d'un répertoire, accélérant ainsi les accès. La réservation retardée permet également de réduire la défragmentation, en attendant d'avoir un certain volume avant de décider de la localisation des données sur le disque. Attention, cela peut entrainer une perte de donnée[x] si un crash arrive avant le flush des données sur disque. Les programmes qui ne demandent pas de vider le cache avant la fermeture du fichier sont vulnérable ( fsync(); fclose() ).

Un mécanisme de défragmentation on-line sera disponible, permettant aux gros fichiers d'être lu de manière séquentielle.

Pour garantir l'intégrité, un mode "barrière" est mis en place, garantissant l'ordre d'écriture sur le disque. En effet, certains disques ré-organisent les lectures et les écritures pour éviter de switcher de mode pour chaque secteur. Cela peut présenter des risques lors de l'écriture des fichiers de logs. La barrière garantie l'écriture des données avant tous autres traitements. Cela a évidement un impact sur les performances et peut être désactivé ( barriers=0 ).

Il n'y aura pas d'ext5, car une nouvelle implémentation est en préparation : btrfs

BTRFS

BTRFS[xi] est une refonte complète du système de fichier, suite[xii] aux travaux de Ohad Rodeh sur les arbres binaires incrémentals[xiii].

Les nouvelles fonctionnalités sont nombreuses :

Par nature le copy-on-write défait toute stratégie d'effacement sécurisé puisque les blocs ne sont pas écrasés mais réécris à côté. Cela peut poser des problèmes de confidentialité. Il n'y a d'ailleurs pas d'option pour chiffrer les blocs. (encryptfs peut être une option)

Il est prévisible que BTRFS soit le prochain système de fichier Linux par défaut d'ici deux ans.

Les benchs publiés présentent des résultats[xiv] contradictoires[xv]

zfs

ZFS[xvi] est gestionnaire de fichier qui mime un gestionnaire de mémoire. Il propose des capacité gigantesque (128 bits), à l'aide de disque mis en commun de tous type (physique, NAS, SAN, baies de disques, etc.). Le mécanisme de transaction permet d'éviter l'utilisation de journal d'entrée-sortie, sans resynchronisation en cas de panne de courant. Les blocs ont des tailles variables, choisie en fonction de la donnée écrite.

Utilisant également le copy-on-write, ZFS défait toute stratégie d'effacement sécurisé. Le chiffrement à la volée est en cours de réalisation, ainsi que la défragmentation on-line.

La licence CDDL[xvii] est incompatible avec la licence Linux, compromettant tous portages. Le rachat de Sun par Oracle fera peut-être évoluer la situation. Des portages[xviii] Linux sont expérimentés.

Tendance générale du domaine

Les nouveaux systèmes de fichiers cherchent à proposer le maximum de fonctionnalité pour répondre aux nouveaux usages. Les gestionnaires orientés Cluster proposent de gérer de très gros volumes en streaming (type vidéo) et en optimisant les accès concurrents. Les données sont dupliquées plusieurs fois sur des disques considérés comme défaillant par nature.

Les gestionnaires orientés OS proposent une gestion d'instantané plus ou moins évolués, et cherchent à améliorer l'intégrité des données et la reprise sur incident. Les volumes traités sont très importants et doivent pouvoir s'amplifier sans interruption de service.

[i]http://www.alfresco.com

[ii]http://fr.wikipedia.org/wiki/IEEE

[iii]http://tinyurl.com/ylnr3kd

[iv]http://tinyurl.com/d3uds

[v]http://tinyurl.com/ycqyrjm

[vi]http://oss.oracle.com/projects/ocfs/

[vii]http://tinyurl.com/yleuyjm

[viii]http://labs.google.com/papers/gfs.html

[ix]http://tinyurl.com/2rz37u

[x]http://tinyurl.com/d9pcfg

[xi]http://tinyurl.com/5n5xjg

[xii]http://tinyurl.com/ygpxd3z

[xiii]http://tinyurl.com/yd5w3mx

[xiv]http://www.linux-mag.com/id/7308/3/

[xv]http://tinyurl.com/cwtw2s

[xvi]http://opensolaris.org/os/community/zfs/

[xvii]http://fr.wikipedia.org/wiki/CDDL

[xviii]http://tinyurl.com/ykhzsp