Jubako n'est pas un système de fichier. Certes il y a Arx qui implémente une archive de fichiers et donc ressemble un peu à un FS readonly, mais ce n'est qu'un cas d'usage de Jubako parmi d'autres.
Pour un stockage style kiwix, tu as besoins de l'url de la ressource web et son mimetype, sans système d’arborescence.
Pour un fichier d'archive, il faut une arborescence et le stockage de toutes les métadonnées d'un fs.
Pour un outils de backup, tu as potentiellement moins d'info à stocker (les dates de création/modification ?) ou plus (un checksum du contenu).
Pour un outils d'archivage, tu es probablement peu intéressé par les droits du fs, l'owner/group... mais tu veux d'autres info (catégorisation, ...)
Pour un distribution de logiciel type rpm/deb, tu te fous des métadonnées, tu veux savoir où installer des fichiers. Par contre tu veux des métadonnées de plus haut niveau (description, version, dépendances, ...)
Un système comme textbundle n'a pas à être obligatoirement structuré avec un zip.
J'ai entendu parlé d'usage où on diffusait des mise à jour de programme télé aux décodeurs des particuliers avec des bdd sqlites. Jubako pourrait être utilisé dans ce cas (je sais pas si ça serait plus adapté ou non, mais c'est un cas d'usage qui sort du classique archive de fichiers)
...
UnionFs, SquashFS, le système de Docker ou Knoppix sont orientés FS. C'est assez générique et tout le monde y est habitué ("tout est fichier" de Unix) mais Jubako sort de ce paradigme et te permet de faire autrement. Arx nous ramène à ça mais je l'ai juste implémenté en premier parce que c'était assez facile et avec des résultats facilement comparables à l'existant. Un avantage de Jubako c'est sa modularité.
Une autre différences, c'est de découplage entre la partie "index" (directory dans la terminologie Jubako) et le contenu. Par exemple pour un système de backup, tu pourrais envoyer tout le contenu sur un serveur distant et garder en local que le directory. Lors des sauvegarde incrémentale, tu as accès, en local, à la liste des fichiers déjà sauvegarder et leur checksums. Tu pourrais faire ton backup totalement en offline, sans avoir toute les sauvegarder en local (et leur occupation disque) et quand même faire de l'incrémental. Tu peux bien sûr faire la même chose avec un json que tu gardes en local, mais Jubako te fournit tout de base.
J'ai évité d'implémenter un équivalent à zim en premier cas d'usage justement pour pas être comparé seulement à zim et limité jubako à un successeur du format zim. Ne comparez pas que Arx avec l'existant :)
J'ai quand même fait un comparatif avec squashfs, ça manque effectivement à la dépêche. J'ai refait les mêmes tests que dans la dépêche (linux complet) avec squasfs. Par défaut squasfs utilise les 16 cœurs de ma machine mais arx est monothreadé. Donc il y a deux séries de tests, un avec squashfs 16 cœurs (pour voir des performances "optimales") et 1 cœur (pour comparer correctement)
Taille
Création
Extraction
Listing
Dump
Dump / entry
Mount diff
Source
1326 MB
880ms
squashfs
177 MB
1m16s
0s730ms
30ms
1m02s
2ms
2,8
squashfs monothread
177 MB
4m38s
1s070ms
30ms
1m02s
2ms
2,8
Arx
140 MB
4m45s
1s47ms
45ms
1m28s
4ms
4s2
Globalement :
- arx compresse mieux
- Est plus lent que squashfs mais reste dans des ordres de grandeurs comparables.
Et il faut se souvenir que squashfs est implémenté dans le kernel (Je sais pas quelle partie est réellement dans le kernel et dans l'userpace pour le listing des fichiers mais pour ce qui est du mount, c'est totalement dans le kernel). Ça m'aurait surpris que arx soit plus rapide qu'un module kernel.
C'est aussi une différence de Jubako avec les autres systèmes. Jubako c'est un lib, elle se veut indépendante de l'OS. À terme, Jubako sera disponible sous Windows et Mac aussi (voir même dans le web en compilant jubako en wasm). Squashfs, t'es limité à linux.
[^] # Re: Bravo !
Posté par GaMa (site web personnel) . En réponse à la dépêche Jubako et Arx, un conteneur universel et son format d’archive. Évalué à 3. Dernière modification le 07 novembre 2022 à 12:14.
Jubako n'est pas un système de fichier. Certes il y a Arx qui implémente une archive de fichiers et donc ressemble un peu à un FS readonly, mais ce n'est qu'un cas d'usage de Jubako parmi d'autres.
UnionFs, SquashFS, le système de Docker ou Knoppix sont orientés FS. C'est assez générique et tout le monde y est habitué ("tout est fichier" de Unix) mais Jubako sort de ce paradigme et te permet de faire autrement. Arx nous ramène à ça mais je l'ai juste implémenté en premier parce que c'était assez facile et avec des résultats facilement comparables à l'existant. Un avantage de Jubako c'est sa modularité.
Une autre différences, c'est de découplage entre la partie "index" (directory dans la terminologie Jubako) et le contenu. Par exemple pour un système de backup, tu pourrais envoyer tout le contenu sur un serveur distant et garder en local que le directory. Lors des sauvegarde incrémentale, tu as accès, en local, à la liste des fichiers déjà sauvegarder et leur checksums. Tu pourrais faire ton backup totalement en offline, sans avoir toute les sauvegarder en local (et leur occupation disque) et quand même faire de l'incrémental. Tu peux bien sûr faire la même chose avec un json que tu gardes en local, mais Jubako te fournit tout de base.
J'ai évité d'implémenter un équivalent à zim en premier cas d'usage justement pour pas être comparé seulement à zim et limité jubako à un successeur du format zim. Ne comparez pas que Arx avec l'existant :)
J'ai quand même fait un comparatif avec squashfs, ça manque effectivement à la dépêche. J'ai refait les mêmes tests que dans la dépêche (linux complet) avec squasfs. Par défaut squasfs utilise les 16 cœurs de ma machine mais arx est monothreadé. Donc il y a deux séries de tests, un avec squashfs 16 cœurs (pour voir des performances "optimales") et 1 cœur (pour comparer correctement)
Globalement :
- arx compresse mieux
- Est plus lent que squashfs mais reste dans des ordres de grandeurs comparables.
Et il faut se souvenir que squashfs est implémenté dans le kernel (Je sais pas quelle partie est réellement dans le kernel et dans l'userpace pour le listing des fichiers mais pour ce qui est du mount, c'est totalement dans le kernel). Ça m'aurait surpris que arx soit plus rapide qu'un module kernel.
C'est aussi une différence de Jubako avec les autres systèmes. Jubako c'est un lib, elle se veut indépendante de l'OS. À terme, Jubako sera disponible sous Windows et Mac aussi (voir même dans le web en compilant jubako en wasm). Squashfs, t'es limité à linux.
Matthieu Gautier|irc:starmad