Discussion:Système de fichiers journalisé

Relecture du document

Bonjour,

Voici nos premières remarques sur le document.

Remarques concernant le résumé introductif

Phrase : Le système de fichiers journalisé est un système de fichiers tolérant/résistant aux pannes qui permet d'assurer l'intégrité des données en cas de problème matériel tel que la panne de courant, le débranchement à chaud ou le crash-kernel.

Formulation :

• La phrase laisse entendre qu'un crash kernel est un problème matériel.
• La panne de courant ou le débranchement à chaud sont-ils des problèmes matériels, et ces deux incident ne recouvrent-ils pas un même type de problème : la coupure de courant ?

Ne vaudrait-il pas mieux séparer ces événements comme suit :

Le système de fichiers journalisé est un système de fichiers tolérant/résistant aux pannes qui permet d'assurer l'intégrité des données en cas de problème matériel, de panne de courant (ou débranchement à chaud ), ou de crash-kernel.

Par ailleurs, même si le lecteur d'un article sur les FS journalisés n'est pas un complet néophyte en informatique, ne vaudrait-il pas mieux remplacer l'anglicisme «crash kernel» qui a une forte connotation Unix par «arrêt brutal du système» par exemple ?

Il est vrai que votre proposition est plus intéressante que ce que j'ai pu proposer. Je vais donc modifier en conséquence. Je remplacerais aussi le terme crash-kernel pour éviter d'avoir un anglicisme dans l'article.

Frédéric Bellano 8 février 2013 à 16:39 (CET)

Phrase : Les systèmes de fichiers doivent pouvoir redémarrer après un crash dans un état dans lequel les méta-données sont cohérentes et relativement à jour.

Formulation : La première impression est qu'on continue à parler ici des FS journalisés.

Une formulation du type :

→Un système de fichiers doit pouvoir redémarrer après un crash dans un état dans lequel les méta-données sont cohérentes et relativement à jour.

montrerait plus qu'on parle des FS en général, alors que "le système de fichiers" ou "les systèmes de fichiers" semblent donner suite à la phrase précédente.

Phrase : La journalisation permet de réduire massivement le temps de restauration du système de fichier après un crash et donc elle est importante dans les environnements qui ont besoin d'une haute disponibilité.

Orthographe : système de fichiers

Formulation :

temps de restauration peut laisser penser qu'il y a un gain lorsqu'on restaure une sauvegarde: temps de contrôle d'intégrité ou :temps de contrôle de cohérence seraient moins ambigus.

Éviter l'usage de formulations de type «donc»... qui laissent entendre qu'il s'agit d'une déduction de l'auteur.

Une suggestion ( à améliorer, la phrase est un peu lourde )

→La journalisation permet de réduire massivement le temps de contrôle d'intégrité du système de fichiers, raccourcissant ainsi le temps de redémarrage du serveur après un crash, critère important dans les environnements qui ont besoin d'une haute disponibilité.

--Gérard Meunier (d) 1 février 2013 à 12:48 (CET)

J'ai modifié la suite du résumé.

Suite aux modifications, je le trouve complet et résume bien l'article

Frédéric Bellano 8 février 2013 à 17:12 (CET)

Remarques sur certaines sections de l'ancienne version

ReiserFS, développé par Namesys, fût introduit dans la branche 2.4.1 de Linux en 2001.

→ ReiserFS, développé par Namesys, fut introduit dans la branche 2.4.1 de Linux en 2001.

XFS, écrit par SGI, était destiné pour le système d'exploitation propriétaire IRIX. C'est en mai 2000 que XFS est publié sous la licence GPL.

→XFS, écrit par SGI, était destiné initialement au système d'exploitation propriétaire IRIX. En mai 2000, XFS est publié sous licence GPL.

La sécurité des systèmes de fichier passe dans un premier temps...

→ La sécurité des systèmes de fichiers passe dans un premier temps...

Phrase : Ceci permet au super-utilisateur de pouvoir se logger sur le système et de faire des tâches administratives quand le système de fichiers est plein pour les utilisateurs.

• L'anglicisme logger pourrait être remplacé par connecté
• L'utilisateur non «Unixien» risque de se demander pourquoi il faut de l'espace pour se connecter.

Beaucoup plus loin dans le document :

restore

Modifie les paramètres du système de fichier

tune2fs

Modifie les paramètres du système de fichiers

sauf erreur...

--Gérard Meunier (d) 1 février 2013 à 13:25 (CET)

Les fautes ont été corrigées et j'ai rajouté une note à la phrase pour expliquer pourquoi sous Linux il faut de la place dans l'espace personnel.

Frédéric Bellano 10 février 2013 à 21:56 (CET)

Section performances ?

Il est fait référence dans le doc à de nouvelles méthodes d'accès aux données ( B+Tree ). On peut penser que ces nouveaux algorithmes d'accès améliorent les performances. Parallèlement le nombre d'écriture sur disque semble augmenté. Quid des performances ?

Il pourrait être intéressant d'ajouter une section sur le sujet. A titre d'information, le document suivant donne des éléments de réponse :

Performance Evaluation of the EXT4 File System A Comparative Study Against EXT3, ReiserFS and JFS

Par: Alireza GHOBADI ; Amir HESAM YARIBAKHT ; Sanam MAHAM ; Mohammad HOSSEIN GHODS ; Hamid R Arabnia ; George A Gravvanis ; Ashu M.G Solo

Conférence:

FCS 2011 : proceedings of the 2011 international conference on foundations of computer science (Las Vegas NV, July 18-21, 2011)

Foundations of computer science. International conference Las Vegas NV, United States

WorldComp'2011 Las Vegas NV, United States

Type de document: Book Chapter

Année: 2011

ISBN: 1601321791

http://cerc.wvu.edu/download/WORLDCOMP%2711/2011%20CD%20papers/FCS4656.pdf

--Gérard Meunier (d) 1 février 2013 à 14:27 (CET)

Autres remarques sur des éléments de la section «Ancienne version»

Récupération rapide sur incident :

1. Mises-à-jour prudentes qui, à un instant précis, rend le système de fichiers cohérent.

2. Les programmes "éboueurs" qui sera expliqué ci-dessous.

Suggestion

1. Procédé des mises à jour prudentes qui, à un instant précis, rend le système de fichiers cohérent.

2. Procédé des programmes "éboueurs" qui sera expliqué ci-dessous.

→ Où sont détaillés les programmes éboueurs ? Si c'est le paragraphe suivant qui y fait référence (ext2 utilise l'utilitaire fsck pour vérifier :l'intégrité et réparer les données. ) il conviendrait de dire :

2. Procédé des programmes "éboueurs" qui est expliqué ci-dessous.

car «sera» laisse entendre que l'explication est plus loin dans le document.

A quoi correspondent les mises à jour prudentes ? Il est fait état quelques lignes plus bas d'un mélange des deux procédés : est-ce bien les programmes éboueurs et les MàJ

Ces changements ont été effectué, ainsi qu'une meilleur explication des deux procédés.

Frédéric Bellano

Jonathan Decrocq

La relation de proportionnalité temps d'analyse/ taille disque est ensuite claire.

En revanche la phrase En effet, pour procéder... est sujette à caution. «En effet» introduit une relation entre l’existence de six phases et le fait que le temps d'exécution soit proportionnel à la taille du support : le nombre de phase multiplie le temps de contrôle, mais n'explique pas la proportionnalité.

→Pour procéder à la vérification ...

Donc plus la taille du support est importante plus les phases seront longues à être exécutées.

Même remarque... il n'y a pas de relation de cause à effet entre l'existence de plusieurs phases et la proportionnalité.

En revanche, et c'est sans doute votre idée, on comprend bien que ce nombre important de phases, au temps d'exécution proportionnel à la surface disque, engendre un très grand temps de remise en état.

Nous avons modifié ce paragraphe en pensant qu'il est maintenant plus claire.

Frédéric Bellano

Jonathan Decrocq

Dans la section XFS : scalable signifie-t-il que le FS est résistant à la montée en charge ?

--Gérard Meunier (d) 5 février 2013 à 15:32 (CET)

Remarques sur le sommaire

De manière générale, le sommaire actuellement en place n'est pas cohérent :

L'on part effectivement d'un chapitre Objectifs suivi des différentes Méthodes de journalisation.

2.3 (Écritures à risque (Write Hazards)) : a creuser doit être débarrassé de ses parenthèses et du a creuser.

Les parenthèses ont été enlevées.

C'est ensuite que j'ai été dérouté par un chapitre qui illustre trois exemples d'implémentation : pourquoi ces trois-ci ? sont-ils les principaux ? pourquoi retrouve-t-on alors en chapitre 6.3 Les principaux systèmes de fichiers journalisés avec à nouveau ext3, mais aussi deux autres systèmes différents de ceux cités dans ce chapitre ?

Pour répondre aux questions.

« pourquoi ces trois-ci ? »

Car ces trois ci sont une implémentation des différentes méthodes de journalisation.

« sont-ils les principaux ? »

Non ceux ne sont pas forcement les principaux systèmes de fichiers journalisés mais ils implémentent chacun l'une des trois méthodes citées juste au dessus.

« pourquoi retrouve-t-on alors en chapitre 6.3 Les principaux systèmes de fichiers journalisés avec à nouveau ext3, mais aussi deux autres systèmes différents de ceux cités dans ce chapitre ? »

Le chapitre 6.3, et d'ailleurs tout le chapitre 6, est en faite ma première version de l'article que j'ai faite. Mais lorsque Mr Grimaud a vérifié notre travail, mon "groupe" a jugé utile de revoir le plan et pour pas supprimer ma version que j'avais faite, ils l'ont mis dans un chapitre à part.

Le chapitre 5 sur les alternatives aurait de mon point de vue été mieux placé à la suite des exemples d'implémentation, pour plus de cohérence, mais cette remarque est ouverte et peut être débattue. Les sous-chapitres sont écrits en anglais : une bonne pratique est d'écrire le titre en français et d'indiquer en note ou entre parenthèse le terme anglais si celui-ci est communément utilisé.

Votre remarque est effectivement meilleure que ce qui est proposé. Je vais donc modifier le plan pour mettre le chapitre 5 à la suite du chapitre 3.

Le chapitre 4 sur les évolutions ne présente uniquement ext2, il est donc difficile d'y déceler une quelconque évolution ! L'on voit apparaitre plus bas 6.2 Évolution des systèmes de fichiers qui semble vouloir relater les mêmes idées ?

Jusqu'ici, la structure du sommaire ressemble à l'article homonyme en anglais [[1]], ce qui n'est nullement un problème en soi, mais ce dernier est assez peu sourcé et en ce sens ne parait pas être un état de l'art à proprement parler.

La suite du sommaire, à partir du chapitre 6 Ancienne version fait réellement coupure avec les chapitres précédents, et donne cette impression d'incohérence générale à la lecture de ce sommaire, d'autant plus que c'est à partir de là que les chapitres sont développés.

Comme répondu plus haut le chapitre 6 est en réalité la première version de l'état de l'art.

--Menard Nicolas (d) 6 février 2013 à 12:13 (CET)

Frederic Bellano 10 février 2013 à 22:31 (CET)

Remarques sur l'Historique

Ce chapitre Historique me parait intéressant quant à la représentation chronologique des divers systèmes de fichiers journalisés, en rapport avec les noms des développeurs ou sociétés instigatrices. Remarque mineure : XFS (2000) devrait apparaître alors au dessus de ReiserFS (2001) ?

Oui vous avez raison c'est juste une erreur de notre part

Cependant, dans le chapitre suivant Évolution des systèmes de fichiers, un tableau apparaît avec un nombre plus important de systèmes fichiers n'apparaissant pas dans lHistorique : est-ce délibéré ? Si oui, en quoi les quatre FS cités sont plus "importants" à présenter que les autres ?

C'est un choix de notre part nous avons cités ces 4 FS car ceux sont principalement des systèmes de fichiers UNIX

Frédéric Bellano

Jonathan Decrocq

Remarques sur l'évolution des systèmes de fichiers

D'une manière générale, ce chapitre s'articule trop autour des systèmes de fichier Linux, par ailleurs bien détaillé et intéressant, il manque cependant à mon avis beaucoup de sources pour chacune de vos affirmations, qui enlèveraient leurs caractères parfois gratuits, parfois trop littéraire (les deux dernières de ma liste :

• La sécurité des systèmes de fichier passe dans un premier temps par l'intégrité des données présentes sur ces derniers. En effet, le système de fichiers doit pouvoir garantir que les données présentes restent bien cohérentes même après un crash du système et doit permettre une récupération sur incident.
• Les fonctionnalités standard de ext2 permettent d'accéder à des partitions de 4 Tera-octets (1 Tera-octets = 1024 Giga-octets), alors que la version ext1 ne permettait que des partitions de 2 Giga-octets (1 Giga-octets = 1024 Méga-octets). La taille maximale des fichiers avec un système ext2 standard est de 2 Giga-octets. De plus, lors de la création du système de fichiers, le système réserve une certaine quantité d'espace pour le super-utilisateur (root), en général 5%. Ceci permet au super-utilisateur de pouvoir se logger sur le système et de faire des tâches administratives quand le système de fichiers est plein pour les utilisateurs
• Suite à un crash, il existe deux procédés pour permettre de récupérer les données : Mises-à-jour prudentes qui, à un instant précis, rend le système de fichiers cohérent. Les programmes "éboueurs" qui sera expliqué ci-dessous.
• ext2, fsck et les six phases
• Ces systèmes ont été conçus pour améliorer la reprise sur incident en s'inspirant des gestionnaires de base de données
• Les systèmes de fichiers journalisés utilisent une nouvelle technologie : le B+Tree. La table d'allocation n'est plus parcourue linéairement mais sous forme d'arbre (Tree). Dans cette structure les feuilles (leaf node en Anglais) sont des pointeurs vers les fichiers. Ce principe est tiré des SGBD.
• Il était donc intéressant de pouvoir mélanger les deux procédés pour avoir une méthode de récupération beaucoup plus rapide.
• C'est ainsi qu'ont vu le jour les systèmes de fichiers journalisés.

Concernant la partie Principaux Systèmes de fichiers journalisés : choix clairement orienté Linux, en quoi sont-ils "principaux" ?

--Menard Nicolas (d) 6 février 2013 à 17:11 (CET)

Organisation du document

Suggestion :

L'évolution vers des systèmes journalisés pourrait éventuellement être placée avant les exemples d’implémentation, voire avant les méthodes. Les aspects historique / besoin ( de FS journalisés ) introduisant le sujet...

--Gérard Meunier (d) 6 février 2013 à 15:46 (CET)

C'est ce que j'avais fais dans mon ancien plan. Mais Mr Grimaud nous a fait la remarque suivante:

Lorsqu'un utilisateur lit la page c'est pour trouver des informations au sujet des systèmes de fichiers journalisés (Comment s'est fait etc...)

C'est pourquoi cette partie est passée en dernière car "peu intéressante" pour les lecteurs mais qui est toujours bon de savoir.

Frederic Bellano 10 février 2013 à 22:50 (CET)

Rapport de relecture

Une remarque générale à propos de cet état de l’art est qu'il n'est à ce jour pas encore finalisé, ce qui rend difficile la lecture critique difficile.

L'absence de réponse sur nos commentaires nous a paru également assez frustrant, certains points que nous avons soulevés et la formulation de certaines de nos remarques pouvaient donner suite à débat, forcément constructif et enrichissant !

Organisation du document

La section concernant l'évolution vers les Systèmes de Fichiers Journalisés pourrait être placée plus avant dans le document, introduisant ainsi la suite du sujet.

Une section consacrée aux performances des Systèmes de Fichiers Journalisés serait bienvenue : si l’on considère les écritures supplémentaires requises pour la journalisation, induit-elle nécessairement une baisse de performances ? Est-il permis de penser que l'adoption d'algorithmes performants tels que le B+Tree joue au contraire en faveur des FS journalisés ? Le document "Performance Evaluation of the EXT4 File System A Comparative Study Against EXT3, ReiserFS and JFS" cité (Section performances) dans le fil de Discussion fournit quelques éléments de réponse sur les performances comparées des système de fichiers.

La présence d’un glossaire serait également un plus dans la lecture de l’article, en évitant des clics vers les pages Wikipédia (cf. plus bas partie Formulation).

Il demeure difficile de juger de la pertinence de l'organisation du document, les différentes sections n'étant pas encore renseignées.

Contenu

De manière générale, le référencement des affirmations par des sources devrait être plus systématique (Remarques sur l'évolution des systèmes de fichiers).

Une erreur apparait sur le tableau des commandes utiles de la section ext3 (Remarques sur certaines sections de l'ancienne version) : la dernière ligne indique restore au lieu de tune2fs.

Le contenu est globalement trop orienté Linux, hormis une apparition de NTFS pour Windows et HSF+ pour Apple dans un tableau, et un chapitre sur XFS.

Manque général d’illustrations : la seule image, illustrant parfaitement le propos auquel elle se rapporte, ne possède pas les bonnes dimensions.

Section Historique : idée très intéressante mais parait incomplet en regard de ce qui est évoqué plus bas dans l’évolution des systèmes de fichiers.

Orthographe

A divers endroits du document "système de fichier" est à corriger (système de fichiers). En dehors de ce point précis, l'orthographe du document nous a paru très correcte.

Formulation

Certaines formulations sont en revanche à revoir :

Utilisation de termes peu compréhensibles pour le néophyte

• crash kernel
• meta-données
• SGBD
• Couche Cache
• super-utilisateur root
• mises à jour prudentes
• programmes éboueurs
• …

Ces termes, bien que pointant souvent sur une page Wikipédia, mériteraient d'apparaître dans un glossaire.

Manque de clarté dans certaines phrases

• « Pour effectuer une opération sur un fichier, par exemple déplacer un fichier A vers B, un système de fichiers journalisé utilise les mêmes procédures basiques (qu’un système de fichiers non-journalisé ?) avec quelques étapes supplémentaires  »
• « Il était intéressant de pouvoir mélanger les deux procédés (lesquels ?) »

Un travail sur la vulgarisation est nécessaire dans certaines sections :

• Fonctionnalités Standards « réservation de la quantité d’espace pour root afin de se connecter au système »
• Récupération rapide sur incident : « Mises à jour prudentes et programmes éboueurs »

…

Quelques déductions peu évidentes

Dans la section Récupération sur incident : « L'inconvénient majeur de cette méthode est le temps d’exécution qui est proportionnel à la taille du support. En effet (?), fsck utilise six phases [...] Donc (?) plus la taille du support est importante plus les phases sont longues [...] Donc (?) il est intéressant de mélanger les deux procédés (lesquels ?) [...]»

Présence d’anglicismes

• crash kernel
• logger
• scalable
• root
• files system
• soft updates …

--Gérard Meunier (d) 6 février 2013 à 21:40 (CET)
--Menard Nicolas (d) 6 février 2013 à 21:40 (CET)