À propos du projet

JuiceFS est un système de fichiers POSIX haute performance publié sous licence Apache 2.0 et conçu pour les environnements cloud-native. Les fichiers écrits via JuiceFS sont persistés dans un stockage objet (par exemple Amazon S3 ou d'autres services compatibles S3), tandis que les métadonnées telles que les noms de fichiers, tailles, permissions, horodatages et la structure des répertoires sont conservées dans un moteur de métadonnées distinct. Les moteurs de métadonnées pris en charge incluent Redis, MySQL, SQLite et TiKV, de sorte que les déploiements peuvent être adaptés à différents scénarios et exigences. Le projet décrit trois parties principales : le client JuiceFS, qui coordonne le stockage objet et le moteur de métadonnées et implémente les interfaces du système de fichiers ; la couche de stockage des données, qui peut utiliser des disques locaux, un stockage objet cloud public ou privé, ou HDFS ; et le moteur de métadonnées. Les fichiers sont divisés en chunks (limite supérieure par défaut de 64 MiB), les chunks en slices, et les slices en blocs (4 MiB par défaut) qui sont stockés dans le stockage objet. En raison de cette organisation, les fichiers sources ne sont pas directement visibles dans un navigateur de stockage objet ; le bucket contient un répertoire chunks avec des répertoires et fichiers numérotés. Les capacités mises en avant dans le README incluent une compatibilité POSIX complète, un SDK Java Hadoop compatible avec Hadoop 2.x et 3.x, une passerelle compatible S3, un pilote CSI Kubernetes, un accès partagé en lecture/écriture depuis des milliers de clients, une cohérence forte où les modifications confirmées sont immédiatement visibles par tous les clients montés, une latence faible et un débit évolutif, le chiffrement en transit et au repos, des verrous de fichiers globaux (BSD flock et POSIX fcntl), et la compression des données avec LZ4 ou Zstandard. Le README mentionne également une cohérence close-to-open, le renommage atomique et les opérations de métadonnées, les fichiers ouverts accessibles après unlink, mmap, fallocate avec prise en charge des punch holes, et les attributs étendus. Il indique que JuiceFS a passé les 8813 tests de compatibilité de la dernière version de pjdfstest. Pour démarrer, il faut un moteur de métadonnées pris en charge, un stockage objet pris en charge et le client JuiceFS. La documentation couvre un guide de démarrage rapide, une référence des commandes, les conteneurs (Docker et Podman), Kubernetes, le SDK Java Hadoop, les bonnes pratiques Redis, la configuration du stockage objet, le cache, le diagnostic des pannes, les options de montage FUSE, l'utilisation sous Windows et la passerelle S3. Des benchmarks sont fournis via une sous-commande JuiceFS, ainsi que des comparaisons fio en lecture/écriture séquentielle et mdtest pour les métadonnées par rapport à EFS et S3FS ; le README présente ces résultats comme favorables et renvoie vers les détails. Le stockage objet pris en charge inclut Amazon S3 et les services compatibles S3, Google Cloud Storage, Azure Blob Storage, Alibaba Cloud OSS, Tencent Cloud COS, Qiniu Kodo, QingStor, Ceph RGW, MinIO, le disque local et Redis, entre autres. Le README indique que JuiceFS est prêt pour la production et utilisé par des milliers de machines, avec une liste d'adopteurs et une documentation d'intégration. Le format de stockage est décrit comme stable et pris en charge par les versions futures. La feuille de route mentionne l'optimisation de la passerelle, la synchronisation reprenable, l'optimisation de la lecture anticipée, l'optimisation des scénarios à grande échelle et les snapshots. JuiceFS collecte des données d'utilisation anonymes par défaut, ne rapportant que des métriques essentielles telles que le numéro de version, et cela peut être désactivé avec l'option --no-usage-report. La conception s'inspire de Google File System, HDFS et MooseFS. Le support communautaire est disponible via GitHub Discussions et Discord, et les problèmes sont suivis sur GitHub.