Le projet UFFS, pour Unified Flash File System est un système de fichiers ayant pour but de supporter tous les périphériques à base de mémoire flash comme les clefs USB, les disques durs SSD, les cartes mémoires (SDCard, MMC...); de plus, il sera disponible, dans sa version finale, sur les systèmes d'exploitation principaux (GNU/Linux, Microsoft Windows, MacOSX).
La première version est attendue courant Juin 2009. Dans un premier temps, le système de fichiers ne fonctionnera qu'en lecture seule. Ceci aura pour objectif d'ouvrir le projet au public afin d'obtenir les premiers retours, ainsi que de permettre de possibles contributions.
Toutes les informations sont sur le site officiel http://uffs.org/. Par ailleurs, nous essayerons de tenir à jour ce journal afin de vous tenir au courant des avancées du projet.
Journal Unified Flash File System
24
mai
2009
# Je ris, mais c'est sûrement pas drôle.
Posté par fleny68 . Évalué à 9.
ça veut dire qu'on va pouvoir lire un système de fichier, mais pas écrire dessus. On va donc pas avoir grand chose à y lire...
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par Corentin Chary (site web personnel) . Évalué à 9.
Donc, il y'aura de quoi lire.
En fait, pour faire un peu plus technique, uffs c'est:
- Un port de UBIFS en userspace sous linux, avec fuse
- Un port de UBIFS en userspace sous windows avec dokan
- Un futur port sous WinCE (kernelspace)
- Un futur port sous Windows (kernelspace)
L'intérêt ? UBIFS est fait pour être conscient des caractéristiques de la mémoire flash: taille minimale d'IO, taille d'un erase block, limitation des écritures/effacements, wear leveling (via UBI en fait).
Du coups, on fait une couche plus générique qu'UBI, qui peut gérer aussi les périphériques (sans wear leveling, ou avec, au choix). Mais on conserve les bonnes pratiques imposées par UBIFS (pas d'écritures plus petites que la taille d'io minimale, on essait d'écrire erase block par erase block).
Voila, pour plus de détails, allez faire un tour sur le site web !
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par M . Évalué à 7.
Sauf que pour les clefs USB, les disques durs SSD, les cartes mémoires (SDCard, MMC...), tu n'as pas acces directement a ces caractérisques.
Tout est masqué par la FLT présente dans le controlleur.
Comment tu vas choisir ta taille d'erase block ?
Comment tu connais la taille io minimale ?
Comment tu peux garantir un résultat correct sans connaître vraiment ce que fait la FTL derrière ton dos.
Certaines FTL/matos sont vraiment foireuse et corrompe tes données de manières invisible.
Pour moi sur ses périphériques il faudrait plutôt mettre un fs qui est robuste aux corruptions aléatoires du support.
PS : http://www.linux-mtd.infradead.org/doc/ubifs.html#L_raw_vs_f(...)
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par M . Évalué à 4.
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par Corentin Chary (site web personnel) . Évalué à 2.
Si t'as des liens, ça m'intéresse.
Mais perso, je pense que ces optimisations sont limitées au wear leveling de la partie fixe de la fat. Et du coups, c'est pas plus mal, parce que c'est aussi par ici que UBIFS stoque les master node (du moins, avec un module EBM sans wear leveling, pas avec UBI).
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par Frédéric COIFFIER . Évalué à 1.
http://www.linux-mtd.infradead.org/doc/ubifs.pdf
Ont-ils tort ?
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par Corentin Chary (site web personnel) . Évalué à 2.
L'idée, c'est de rajouter une couche, qui permet d'utiliser au choix, UBI, un périphérique block, ou autre chose.
Le fait est qu'on à actuellement une version de ubifs qui tourne en userspace et qui est capable d'utiliser ces supports.
C'est déjà faisable avec le ubifs de base, et block2mtd, mais ça rajoute pas mal d'overhead.
Mais oui, UBIFS n'as pas été crée pour ça à la base.
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par William Dauchy (site web personnel) . Évalué à 1.
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par Corentin Chary (site web personnel) . Évalué à 2.
C'est quand même vachement souvent 128K.
Comment tu connais la taille io minimale ?
Entre 512 et 4K, la majorité c'est 2K. Sur un SSD/Clef USB/.. c'est normalement la taille d'un secteur. Ou au moins, la taille d'un secteur est une valeur qui sera bonne.
Comment tu peux garantir un résultat correct sans connaître vraiment ce que fait la FTL derrière ton dos.
En gros, http://tytso.livejournal.com/60368.html
Certaines FTL/matos sont vraiment foireuse et corrompe tes données de manières invisible.
UBIFS est plein de crc de partout, ça permet déjà de détecter ces corruptions aléatoires.
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par mr_pouit (site web personnel) . Évalué à 1.
Il me semble que la plupart des SSD remontent des valeurs débiles du genre 512 octets/secteur pour garder une vague compatibilité avec les disques durs... donc la valeur ne sera pas super adaptée au SSD...
Comment tu peux garantir un résultat correct sans connaître vraiment ce que fait la FTL derrière ton dos.
Tu peux faire des hypothèses et tirer des conclusions de certains tests, jusqu'à la prochaine révision de la FTL qui t'obligera à tout refaire. Ou pire, les déductions ne seront valables que pour ce SSD-ci et pas celui d'un autre fabricant :(...
Certaines FTL/matos sont vraiment foireuse et corrompe tes données de manières invisible.
Certains fabricants de Flash "inventent" des trucs (genre http://download.micron.com/pdf/technotes/nand/tn2941_idm_cop(...) ) pour essayer d'éviter ça...
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par benoar . Évalué à 4.
Un périphérique bloc sous linux apparaît comme ayant des secteurs de 512 octets, ce n'est pas pour être "vaguement compatible" (comme écrit en dessous), c'est parce que c'est le _fondement_ même d'un périphérique de type bloc ! Tout le système des block io de linux et des autres OS est basé sur cette assomption.
Ensuite, tu n'as aucun contrôle sur comment est géré le cache, l'écriture, etc. de tes blocs derrière, à moins de tripatouiller dans le système de gestion de périphs bloc du kernel.
Pour tes valeurs d'erase block, de taille de page et autre, tu dis du "vachement souvent" ou "normalement" : déjà, la quasi totalité des constructeurs ne communiquent pas dessus, et les seuls que j'ai pu voir étaient tous différents.
Et de toute façon, comment sais-tu de quelle façon va gérer la FTL derrière ? Peut-être qu'elle flush tout à chaque écriture d'un bloc (= effacement d'un erase block qqpart, récriture du contenu en entier + tes nouvelles données .... super efficace ; je soupçonne les clés USB de faire ça, vu leur durée de vie), ou alors peut-être est-elle plus "intelligente", mais comment va se comporter ton algo avec ça ?
Bref, je ne comprend pas vraiment l'utilité du truc si vous (j'ai cru comprendre que tu faisais également partie du projet) n'avez pas au moins une connaissance solide de ce sur quoi vous bossez.
Voilà, tout ça sans parler du "problème", si votre objectif est de faire quelque chose qui marche partout (vu que vous faites du windows aussi, je suppose que c'est un peu votre objectif) d'arriver à avoir un format assez répandu pour être lu de manière pratique sur beaucoup de machines ...
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Non. Un périphérique bloc peut avoir des blocs de taille différente.
J'ai vu une clef USB avec des blocs de 2 ko, qui fonctionnait à merveille sous Linux, qu'on pouvait partitionner avec Parted et tout. Comme c'était une clef de promotion Microsoft, je pense qu'elle devait être bien prise en charge également sous Windows.
Bref, je ne comprend pas vraiment l'utilité du truc si vous (j'ai cru comprendre que tu faisais également partie du projet) n'avez pas au moins une connaissance solide de ce sur quoi vous bossez.
Tel que je vois les choses, un SSD, une clef USB ou n'importe quel medium de stockage par blocs devrait exposer une taille de bloc optimale pour son travail. Si ma clef USB expose des blocs de 512 octets, et que ses eraseblocs font 4 ko, c'est le problème de son fabricant qui est un tocard, et ce n'est certainement par le du système de fichiers, de la couche d'accès blocs ou du système d'exploitation. Donc pas au système de se préoccuper de ça : utilisons les blocs fournis par les périphériques.
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par benoar . Évalué à 4.
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par Maclag . Évalué à 2.
Tout système de block Io de Linux montera au ciel... et je viens de comprendre que le Paradis est en orbite autour de Jupiter! \o/
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par mr_pouit (site web personnel) . Évalué à 2.
Oui, mais ce n'est pas vraiment adapté aux SSD (qui ont généralement des pages de 2K ou plus)... C'est pour ça que j'ai dit "vaguement compatible", car ils ont choisi de les montrer comme des périphériques de type bloc car certains OS ne connaissent pas autre chose et comme ça, la diffusion des SSD se fait mieux, même si ça oblige à avoir des FTL qui font des trucs de psychopathes derrière ton dos.
Pour tes valeurs d'erase block, de taille de page et autre, tu dis du "vachement souvent" ou "normalement" : déjà, la quasi totalité des constructeurs ne communiquent pas dessus, et les seuls que j'ai pu voir étaient tous différents.
Il y en a beaucoup, mais ça reste dénombrable : 512 pour les petites capacités, puis 2k, 4k ou 16k selon le type de Flash (MLC ou SLC), la capacité et le fabricant (comment ça c'est le bordel ?). Mais c'est vrai qu'avec l'interface bloc il n'y a aucun moyen de remonter des infos comme ça ("youhou, j'utilise des pages de 2k et des erase blocks de 128k"), et je suis pas sûr que ça va mieux marcher si on fait des suppositions hasardeuses ("bon allez, on considère qu'ils ont tous des pages de 4k")...
D'un autre côté, si on pousse un peu le raisonnement, on s'en fout un peu : considérer les SSD d'après les caractéristiques de la mémoire Flash utilisée est une simplification un peu rapide et risquée, étant donné que tout passe par la FTL, qui est fermée, non documentée, et qui fait ce que bon lui semble (rien que les premières générations de SSD qui ont des perfs immondes lors d'IO en parallèle alors qu'ils sont composés de plusieurs puces Flash, donc en théorie plusieurs accès concurrents possibles...).
Et de toute façon, comment sais-tu de quelle façon va gérer la FTL derrière ?
Je ne veux pas prendre leur défense, mais sur le coup, _personne_ ne sait ce que font les FTL (bon, ok, les gens qui les codent, et c'est tout). On peut avoir plusieurs indications en lisant les brevets déposés (beurk, indigestes) ou les quelques articles ou papiers qui parlent des FTL (BAST, FAST, STAFF, DFTL, SuperBlock...), mais une nouvelle fois, rien n'indique qu'ils sont implantés...
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par benoar . Évalué à 3.
Ensuite, ce coté bloc de 512, quand je disais que c'était inhérant au système de bloc, ce n'est pas que ça, c'est aussi inhérant à la norme ATA ! (et donc SATA) Bref, ce n'est pas qu'un problème de soft, c'est aussi un problème de hard (enfin, moitié/moitié puisque la stack ATA c'est un bout de driver et un bout de hard). Donc ce n'est pas près, selon moi, de changer.
Comme personne n'a poussé pour un système de connexion spécifique aux mémoires Flash (on aurait peut-être pu faire quelque chose "au dessus" du protocole physique SATA, voire encore plus crade mais plus "facile", au dessus des commandes ATA ?) et bien tout le monde fait des FTL. Et effectivement, personne ne sait ce qu'il fait, garder des secrets ça arrange bien les industriels.
Enfin bref, pour les histoires de capacités, c'est peut-être facile aujourd'hui, mais j'ai entendu que pour simplifier le design des puces de grosses capacités, ils voulaient faire des erase block dont la taille se compte en Mb, ce qui ne va pas arranger les choses. D'ailleurs c'est peut-être déjà le cas, mais on n'en sait rien. Encore du secret.
Pour conclure, oui ce serait bien d'arriver à faire un truc adapté (et libre, en plus) mais je ne pense pas que ce soit faisable vu le comportement des industriels aujourd'hui.
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par Corentin Chary (site web personnel) . Évalué à 2.
Ensuite, ce coté bloc de 512, quand je disais que c'était inhérant au système de bloc, ce n'est pas que ça, c'est aussi inhérant à la norme ATA ! (et donc SATA) Bref, ce n'est pas qu'un problème de soft, c'est aussi un problème de hard (enfin, moitié/moitié puisque la stack ATA c'est un bout de driver et un bout de hard). Donc ce n'est pas près, selon moi, de changer.
Et bah ... justement si. D'une part la transition vers des secteurs de 4K est en cours.
D'autre part, des commandes ATA spécifiques aux SSD apparaissent (voir TRIM/Discard)
Toutes ces infos, on les trouve sur lwn.net, ou dans le blog de Ted T'so cité précédemment.
[^] # Re: Je ris, mais c'est sûrement pas drôle.
Posté par benoar . Évalué à 2.
Oui, c'est plus pratique aujourd'hui pour s'aligner à la taille des pages en RAM, et s'adapter plus facilement aux FS, et pour les grandes tailles de disque. Mais ça ne change rien pour les SSD qui ont des tailles de page différentes. À moins qu'il y ait un effort d'unification à 4ko ? Mais je n'en ai jamais entendu parler. Et puis ça ne règle pas le problème de la taille des erase-block, ni même des "zones" si on passe par une FTL bas de gamme.
des commandes ATA spécifiques aux SSD apparaissent (voir TRIM/Discard)
Oui enfin encore une fois, c'est une adaptation aux FTL, pour qu'elles soient utilisées un peu mieux (enfin, pour qu'elles ne soient pas complètement nazes ... ce qui est mieux que rien, mais pas top). Et ça existait déjà dans les specs CompactFlash (en mode ATA), même si à priori ça n'a jamais été implémenté par personne ... Et puis surtout ça devient assez drôle au niveau des implications que ça a par rapport aux utilisations un peu inhabituelles comme l'accès direct (sans passer par le FS) ou la récupération de données, cf http://marc.info/?l=linux-ide&m=123266840917245&w=2 et suivants, j'ai le flemme d'expliquer pour l'instant.
Bref, ça n'améliore qu'un peu la situation, et surtout, c'est fait dans l'esprit de garder absolument les FTL, pas d'imaginer de travailler sans.
# Disque dur SSD
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
D'ailleurs, le mot « drive » est déjà présent dans le sigle SSD, donc parler de lecteur SSD, c'est comme parler de disque CD…
[^] # Re: Disque dur SSD
Posté par William Dauchy (site web personnel) . Évalué à 4.
On veillera à corriger cette erreur à l'avenir.
Merci.
[^] # Re: Disque dur SSD
Posté par gUI (Mastodon) . Évalué à 3.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# UID optionnels ou mapping d'UID ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
En clair : les permissions Unix, c'est cool… sauf sur les périphériques qui servent pour échanger des documents, où c'est franchement nuisible.
Donc, s'il vous plaît, dans ce système de fichiers du futur, pourriez-vous, au choix :
- rendre optionnelle la prise en charge des UID, et en faire une option du système de fichiers ;
- proposer un mécanisme de mapping d'UID, en option de montage ?
[^] # Re: UID optionnels ou mapping d'UID ?
Posté par sebbu . Évalué à 3.
[^] # Re: UID optionnels ou mapping d'UID ?
Posté par teddyber . Évalué à 2.
[^] # Re: UID optionnels ou mapping d'UID ?
Posté par Batchyx . Évalué à 1.
Bon, OK, même windows sait recoller des fichiers en ligne de commande ...
[^] # Re: UID optionnels ou mapping d'UID ?
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 5.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: UID optionnels ou mapping d'UID ?
Posté par Octabrain . Évalué à 4.
[^] # Re: UID optionnels ou mapping d'UID ?
Posté par Corentin Chary (site web personnel) . Évalué à 3.
Par contre, à mon avis, il suffirait de patcher le vfs pour avoir cette fonctionnalité dans tout les FS.
# Sur les systèmes d'exploitation principaux...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
[^] # Re: Sur les systèmes d'exploitation principaux...
Posté par William Dauchy (site web personnel) . Évalué à 0.
[^] # Re: Sur les systèmes d'exploitation principaux...
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Bon, à vrai dire, s'il y a le support d'OS X, je ne me fais pas trop de soucis. Mais j'espère quand même que le développement ne sera pas trop "orienté" (c'est à dire que j'espère que si ce système de fichiers est porté sur BSD, ça sera simple car proprement codé et pensé pour la portabilité, pas un gros bouzin qui ne tourne que sur une seule distribution linux).
[^] # Re: Sur les systèmes d'exploitation principaux...
Posté par Corentin Chary (site web personnel) . Évalué à 1.
Donc FreeBSD, ça sera pas le plus dur.
Par contre, je ne pense pas qu'ils aient le support de TRIM/Discard pour les périph block. Et je ne sais pas trop ce qu'ils ont pour gérér la mémoire flash "nue".
# Et le fonctionnel ...
Posté par Francois G. (site web personnel) . Évalué à 4.
Une partition sur un SSD pour le système (2 Go). Très rapide en temps d'accès et en lecture.
Une partition sur un SSD pour les applications (14 Go). Rapide en temps d'accès et en lecture.
Une partition sur disque dur pour les données.
Votre système de fichiers semble prendre en compte les spécificités matérielles.
Peut il prendre en compte les spécificités fonctionnelles ?
La taille d'une partition (2 Go ou 16 Go) sur SSD fait-elle varier le temps d'accès et la vitesse de lecture sur la partition ?
Y a-t-il des optimisations possibles à attendre dans ce sens ?
[^] # Re: Et le fonctionnel ...
Posté par Corentin Chary (site web personnel) . Évalué à 3.
[^] # Re: Et le fonctionnel ...
Posté par Francois G. (site web personnel) . Évalué à 2.
Outre les performances mécaniques des puces, il faudra un système de fichier pour optimiser le fonctionnement de l'ensemble.
La diffusion de masse de votre travail passera, à mon avis, par un plus au niveau des performances et de la fiabilité...
Quitte à sortir des standards et modèles actuels.
Je ne crois pas à la généralisation d'un système de fichier 'universel' pour les mémoires flash.
Ou alors, ça viendra d'une grosse structure en libre ou pas libre (Vous avez prévu de faire racheter votre travail ???)
[^] # Re: Et le fonctionnel ...
Posté par Corentin Chary (site web personnel) . Évalué à 1.
Je sais pas si il existe déjà quelque chose qui va dans ce sens sous Linux.
[^] # Re: Et le fonctionnel ...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Sous Linux, non, mais sous Unix, oui, depuis le début. Il me semble que /bin et /usr/bin sont distincts pour pouvoir mettre /bin (qui sert plus souvent) sur un tambour magnétique plus rapide que le reste.
[^] # Re: Et le fonctionnel ...
Posté par Francois G. (site web personnel) . Évalué à 2.
Pour 10 euros, tu as une clé USB de 8Go aujourd'hui, probablement 16 Go dans un an.
ReadyBoost n'est qu'un cache car le système est tellement lourd qu'il ne tient pas sur une mémoire flash... ou celle ci est hors de prix.
Si j'ai un SSD et un disque dur sur mon ordi, je fais un / pour le SSD et un /home sur le disque dur, pas de soucis.
Les puces mémoires dont je parle remplacent le SSD.
Il n'y aurait pas de 'nappe' mais un bus de communication, donc plus rapide au niveau matériel.
Mais pour ça, il faut le système de fichier qui optimise tout ça. Surtout en lecture.
De même qu'il ne sert à rien de faire des SSDs de 100 Go pour les particuliers.
Trop cher pour le gain à l'utilisation.
[^] # Re: Et le fonctionnel ...
Posté par claudex . Évalué à 1.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.