Discussion:Système de fichiers journalisé

message: 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)
thread_title: Section performances ?

message: :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  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 , 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é. 
:→ à la vérification ...
: 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)
thread_title:  Autres remarques sur des éléments de la section «Ancienne version»

message: :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.
::
::Car ces trois ci sont une implémentation des différentes méthodes de journalisation. 
::
::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. 
::
::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 [], 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)
replies: text: Frederic Bellano 10 février 2013 à 22:31 (CET)
thread_title:  Remarques sur le sommaire 

message: 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)
thread_title:  Remarques sur l'évolution des systèmes de fichiers 

message: 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)
thread_title:  Rapport de relecture 

message: 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)
thread_title: Formulation

message: *crash kernel
*logger
*scalable
*root
*files system
*soft updates …
--Gérard Meunier (d) 6 février 2013 à 21:40 (CET)
thread_title: Présence d’anglicismes