Les systèmes de fichiers

Recherche de documentations

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour à tous,

Je recherche en ce moment de la documentation sur les systèmes de fichiers.

Sur mon site internet, actuellement en travaux, j'ai intégré mon premier prototype l'année dernière. Les articles actuellement disponibles viennent en quelques sortes d'un disque dur virtuel. Celui-ci est fonctionnel, bien que très loin des performances que j'espère de lui. Depuis quelques mois, je planche dessus et j'ai résolu la plupart des problèmes au niveau des lectures / écritures. La dernière étape ce sera la sécurité, puis-ce que la version actuel de XAT (Xanta Allocation Table) implémentait le chiffrement au niveau du fichier de stockage - c'est un manque de performance évident. Mais ce n'est pas la question, je pense être capable d'adapter mes propres systèmes de chiffrement à ce DD virtuel. :)

L'intérêt du sujet porte plutôt sur les avantages et les inconvénients des systèmes de fichiers actuellement disponible sur le marché : ISO 9660 (fichier .iso), EXT2/3/4, NTFS, FAT16/32 etc. Et surtout sur leurs structures présentés sous cette forme de préférence. Les fichiers .iso m'intéressent particulièrement, puis-ce que le fonctionnement sera probablement du même ordre.

Je suis sûr que je peux compter sur la communauté. ;)

Merci d'avance !

Tant de choses, tant de vies, tant de possibilités.

+0 -0

Cette réponse a aidé l'auteur du sujet

Tu es conscient que ce type de structure n'existe pas forcément dans un système de fichier ? La table d'allocation de fichiers, c'est super contraignant: il faut la mettre à jour au fur et a mesure que tu remplis ton disque, sous peine d'avoir de l'espace occupé mais non répertorié, ça fait beaucoup d'accès sur la table, et, si la table se retrouve corrompue, les dégâts sont immenses, donc le système de fichier n'est pas robuste aux erreurs d'écritures, ruptures d'alimentation, etc… Sans compter que ce n'est pas efficace sur un système qui n'est pas en temps d'accès constant (ce qui comprend toutes les mémoires de masse actuelles).

Ext3 est journalisé, il devrait donc éviter ce problème, mais je ne suis pas expert des systèmes de fichiers pour disque dur. Par contre, à priori, c'est pas adapté pour travailler en RAM ou sur un fichier (lui même géré par système de fichiers).

+0 -0
Auteur du sujet

Bonjour Natalya,

Non, je ne savais pas du tout. J'étais partie sur l'idée de journaliser les modifications (pour ne pas ré-écrire le fichier), mais je pensais quand même restructurer le DD virtuel de temps en temps pour que la table d'allocation retourne les pointeurs de manière plus optimisé.

Merci pour ta réponse. :)

Édité par Yarflam

Tant de choses, tant de vies, tant de possibilités.

+0 -0
Auteur du sujet

De nouveau sur le topic, j'ai une petite problématique : Quel délimiteur me conseillerez-vous pour séparer des blocs de données de taille variable ?

J'ai soit la possibilité d’interdire un groupe de bits ou d'octets, soit déclarer à l'avance la taille de ma chaîne, soit indiquer un pointeur et reporter mon contenu dans les clusters virtuels. Existe t-il d'autres solutions ? Laquelle offrirait un meilleur compromis mémoire / temps ?

Autre souci, c'est l'héritage dossier & fichier. Je ne sais pas comment ça se passe dans un DD classique, mais ma première version utilisait les chemins complets. Ce qui est d'un côté plutôt rapide - on n'explore pas les héritages - mais c'est quand même un contenu supplémentaire, sans compter que l'on ne peut pas priver l'accès à des répertoires ou ajouter des métadonnées.

Ces questions sont en quelques sortes les méthodes de conceptions qu'il me manque - après l'aspect technique je le maîtrise.

Comme disait Nicolas Boileau "Ce que l'on conçoit bien s'énonce clairement, Et les mots pour le dire arrivent aisément". :)

Édité par Yarflam

Tant de choses, tant de vies, tant de possibilités.

+0 -0
Auteur du sujet

Je viens de me remettre un peu dans le cambouis. :)

Tout d'abord, j'ai résolu une partie de mon précèdent post - puis-ce qu'il existe une autre manière de délimiter un champ à taille variable : on peut tout simplement doubler un octet pour valider une opération. Par exemple, \x00 pourrait être une commande d'arrêt du champ. Pour valider, il faut tout simplement le doubler. \xA5\x13\x78\x00\x00. Au contraire, si on veut enregistrer \x00 on utilisera par exemple \x01, \xA5\x13\x78\x00\x01\x14\x00\x00 donnera donc \xA5\x13\x78\x00\x14. La perte en mémoire est finalement minime et ça permet d'indiquer des champs textes sans aucun soucis, voir même d'étendre des commandes systèmes.

Pour l'héritage, je me demandais si un système de jump serait envisageable. Finalement le contenu d'un fichier peut-être morcelé par des blocs. En réattribuant une zone libre, on peut indiquer le numéro du bloc suivant (que ce soit pour le contenu du fichier, comme pour son antécédent hiérarchique - le répertoire).

Le problème peut se poser sur le temps, si la zone libre ne dispose pas d'assez d'espace. La solution serait de décaler l'ensemble - ce que l'on appelle typiquement la défragmentation. Rien d'innovant en effet - mais mon projet, rien que d'y penser conceptuellement à la manière d'agencer les données et les fonctions de lecture / écriture m'apporte beaucoup sur ce qu'on peut faire et je souhaiterai créer un Web OS optimisé qui apporterait des idées innovantes par là suite.

Si vous avez des idées à m'apporter. Des structures de données qui pourraient m'intéresser, je suis preneur. :D

Merci.

Édité par Yarflam

Tant de choses, tant de vies, tant de possibilités.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte