Lorsque les utilisateurs choisissent un système de fichiers, la compatibilité sémantique POSIX est un indicateur indispensable. JuiceFS a toujours attaché une grande importance à la haute compatibilité avec la norme POSIX et a fait de son mieux pour maintenir le degré maximum de compatibilité POSIX tout en améliorant continuellement les fonctions et les performances.
Récemment, en termes de compatibilité POSIX, nous avons effectué un test sur Tencent Cloud CFS, Alibaba Cloud NAS, Huawei Cloud SFS, GCP Filestore, Amazon EFS, les partages de fichiers Azure et JuiceFS, afin que les utilisateurs puissent comprendre les performances de compatibilité de ces fichiers grand public. systèmes.
POSIX est l'abréviation de Portable Operating System Interface (Portable Operating System Interface).En termes simples, il s'agit de la spécification d'interface de système d'exploitation la plus largement utilisée dans le domaine du stockage de fichiers, y compris le stockage de fichiers. Pour plus de discussions sur la norme POSIX, vous pouvez vous référer à une question et réponse sur Quora " Que signifie la conformité/conformité POSIX dans le monde des systèmes distribués ?"
Méthodes d'essai
Pour tester la compatibilité POSIX du système de fichiers, un ensemble de cas de test populaire est pjdfstest , qui provient de FreeBSD et s'applique également à des systèmes tels que Linux.
Résultats de test
Les résultats des tests sont présentés dans la figure ci-dessus, JuiceFS a 0 cas d'échec, montrant la meilleure compatibilité. GCP Filestore a suivi avec deux échecs ; Huawei Cloud SFS, Amazon EFS et les partages de fichiers Azure ont échoué à des cas de test qui étaient de plusieurs ordres de grandeur plus importants que d'autres produits. Pour faciliter la comparaison, l'abscisse dans la figure ci-dessus utilise des coordonnées logarithmiques.
Analyse de cas d'échec
Les cas d'échec des partages de fichiers HUAWEI CLOUD SFS, Amazon EFS et Azure sont beaucoup plus élevés que ceux des autres systèmes de fichiers en termes de nombre total et de catégorie, ils ne peuvent donc pas être comparés dans le même graphique et seront analysés séparément plus tard.
Magasin de fichiers GCP
GCP Filestore a échoué à 2 tests au total, un pour les catégories unlink et utimesat.
Le premier élément est unlink/14.t dans l'ensemble de test unlink et les journaux correspondants sont les suivants.
/root/pjdfstest/tests/unlink/14.t ...........
not ok 4 - tried 'open pjdfstest_b03f52249a0c653a3f382dfe1237caa1 O_RDONLY : unlink pjdfstest_b03f52249a0c653a3f382dfe1237caa1 : fstat 0 nlink', expected 0, got 1
Cette suite de tests ( unlink/14.t ) est utilisée pour vérifier le comportement d'un fichier qui est supprimé alors qu'il est ouvert :
desc="An open file will not be immediately freed by unlink"
L'opération de suppression d'un fichier correspond en fait à unlink au niveau du système, c'est-à-dire à supprimer le lien du nom de fichier vers l'inode correspondant, et à décrémenter la valeur nlink correspondante de 1. Ce cas de test permet de vérifier ce point.
# A deleted file's link count should be 0
expect 0 open ${n0} O_RDONLY : unlink ${n0} : fstat 0 nlink
Le contenu du fichier n'est réellement supprimé que lorsque le nombre de liens (nlink) est réduit à 0 et qu'aucun descripteur de fichier ouvert (fd) ne pointe vers le fichier. Si nlink n'est pas correctement mis à jour, des fichiers qui auraient dû être supprimés peuvent rester sur le système.
L'autre élément est utimesat/09.t dans l'ensemble de test utimesat , et les journaux correspondants sont les suivants :
/root/pjdfstest/tests/utimensat/09.t ........
not ok 5 - tried 'lstat pjdfstest_909f188e5492d41a12208f02402f8df6 mtime', expected 4294967296, got 4294967295
Ce scénario de test nécessite la prise en charge des horodatages 64 bits. GCP Filestore prend en charge l'horodatage 64 bits, mais il diminuera de 1 sur cette base, donc bien qu'il échoue dans ce cas de test, cela ne devrait pas affecter l'utilisation de .
Tencent Cloud CFS
Tencent Cloud CFS a échoué à 7 éléments dans trois catégories : utimesat, lien symbolique et dissociation. Nous avons sélectionné quelques éléments de défaillance importants pour analyse et explication.
Le journal de test correspondant au cas d'échec du lien symbolique est le suivant :
/root/pjdfstest/tests/symlink/03.t ..........
not ok 1 - tried 'symlink 7ea12171c487d234bef89d9d77ac8dc2929ea8ce264150140f02a77fc6dcad7c3b2b36b5ed19666f8b57ad861861c69cb63a7b23bcc58ad68e132a94c0939d5/.../... pjdfstest_57517a47d0388e0c84fa1915bf11fe4a', expected 0, got EINVAL
not ok 2 - tried 'unlink pjdfstest_57517a47d0388e0c84fa1915bf11fe4a', expected 0, got ENOENT
Failed 2/6 subtests
Cet ensemble de test ( symlink/03.t ) est utilisé pour tester le comportement de symblink lorsque le chemin dépasse la longueur PATH_MAX.
desc="symlink returns ENAMETOOLONG if an entire length of either path name exceeded {PATH_MAX} characters"
Le code correspondant du cas d'utilisation ayant échoué est le suivant :
n0=`namegen`nx=`dirgen_max`nxx="${nx}x"
mkdir -p "${nx%/*}"
expect 0 symlink ${nx} ${n0}
expect 0 unlink ${n0}
Ce cas de test consiste à créer PATH_MAXun lien symbolique de longueur (y compris le 0 final), mais il ne parvient pas à montrer qu'un lien symbolique PATH_MAXde .
Alibaba Nuage NAS
Alibaba Cloud NAS a échoué plusieurs cas de test sur chmod, utimesat, unlink.
Dans l'ensemble de test de chmod chmod/12.t , Alibaba Cloud NAS a échoué aux éléments suivants
/root/pjdfstest/tests/chmod/12.t ............
not ok 3 - tried '-u 65534 -g 65534 open pjdfstest_db85e6a66130518db172a8b6ce6d53da O_WRONLY : write 0 x : fstat 0 mode', expected 0777, got 04777
not ok 4 - tried 'stat pjdfstest_db85e6a66130518db172a8b6ce6d53da mode', expected 0777, got 04777
not ok 7 - tried '-u 65534 -g 65534 open pjdfstest_db85e6a66130518db172a8b6ce6d53da O_RDWR : write 0 x : fstat 0 mode', expected 0777, got 02777
not ok 8 - tried 'stat pjdfstest_db85e6a66130518db172a8b6ce6d53da mode', expected 0777, got 02777
not ok 11 - tried '-u 65534 -g 65534 open pjdfstest_db85e6a66130518db172a8b6ce6d53da O_RDWR : write 0 x : fstat 0 mode', expected 0777, got 06777
not ok 12 - tried 'stat pjdfstest_db85e6a66130518db172a8b6ce6d53da mode', expected 0777, got 06777
Failed 6/14 subtests
Cet ensemble de test ( chmod/12.t ) est utilisé pour tester le comportement des bits SUID/SGID
desc="verify SUID/SGID bit behaviour"
Nous sélectionnons les 11e et 12e cas de test pour expliquer en détail, et couvrons ces deux bits d'autorisation en même temps
# Check whether writing to the file by non-owner clears the SUID+SGID.
expect 0 create ${n0} 06777
expect 0777 -u 65534 -g 65534 open ${n0} O_RDWR : write 0 x : fstat 0 mode
expect 0777 stat ${n0} mode
expect 0 unlink ${n0}
Ici, nous créons d'abord le fichier cible avec l'autorité 06777, puis modifions le contenu du fichier et vérifions si le SUID et le SGID sont correctement effacés. Le 777 dans le fichier permission est connu de tous, il correspond au rwx de owner, group et other, ce qui signifie lisible, inscriptible et exécutable. Le 0 initial indique un nombre octal.
Il faut expliquer avec insistance le deuxième chiffre 6. Cet octet (octet) représente un bit d'autorisation spécial, et les deux premiers chiffres correspondent à setuid/setgid (ou SUID/SGID), qui peut être appliqué aux fichiers exécutables et aux répertoires publics. Lorsque ce bit d'autorisation est défini, tout utilisateur exécutera le fichier en tant que propriétaire (ou groupe). Cet attribut spécial permet à un utilisateur d'accéder aux fichiers et répertoires normalement disponibles uniquement pour le propriétaire. Par exemple, la commande passwd définit l'autorité setuid, qui permet aux utilisateurs ordinaires de modifier le mot de passe, car le fichier qui enregistre le mot de passe n'est accessible qu'à root et l'utilisateur ne peut pas le modifier directement.
Le point de départ de la conception de setuid/setgid est de fournir aux utilisateurs un moyen d'accéder aux fichiers restreints (n'appartenant pas à l'utilisateur actuel) de manière limitée (en spécifiant les fichiers exécutables). Par conséquent, lorsque le fichier est modifié par un non-propriétaire, ce bit d'autorisation doit être automatiquement effacé pour empêcher les utilisateurs d'obtenir d'autres autorisations via cette méthode.
D'après les résultats des tests, nous pouvons voir que dans le NAS Alibaba Cloud, lorsque le fichier est modifié par un non-propriétaire, les setuid/setgid ne sont pas effacés, de sorte que l'utilisateur peut réellement effectuer n'importe quelle opération en tant que propriétaire en modifiant le fichier contenu, ce qui posera un problème .
Lectures complémentaires : Autorisations de fichiers spéciales (setuid, setgid et Sticky Bit) (Guide d'administration système : Services de sécurité)
Huawei Cloud SFS et Amazon EFS
HUAWEI CLOUD SFS et Amazon Elastic File System (EFS) ont échoué de la même manière dans le test pjdfstest. Le taux d'échec est d'environ 21 % et les cas d'échec couvrent presque toutes les catégories.
Les deux prennent en charge le montage NFS, mais la prise en charge des fonctionnalités NFS est incomplète. Par exemple, les périphériques de bloc et les périphériques de caractère ne sont pas pris en charge, ce qui entraîne directement l'échec d'un grand nombre de cas de test dans pjdfstest. Après avoir exclu ces deux types de fichiers, il existe encore des centaines de types de pannes différents, il doit donc être utilisé avec prudence dans les scénarios complexes .
Partages de fichiers Azure
Le taux d'échec des partages de fichiers Azure a atteint 62 %, ce qui montre que certains scénarios POSIX de base peuvent avoir des problèmes d'incompatibilité. Par exemple, l'autorisation par défaut des partages de fichiers Azure et des dossiers est 0777, le propriétaire est root et la modification n'est pas prise en charge, c'est-à-dire qu'il n'y a aucune restriction d'autorisation. De plus, les partages de fichiers Azure ne prennent pas en charge les liens physiques et les liens symboliques. Par conséquent, l'utilisation d'Azure File Shares nécessite des tests minutieux et une réflexion approfondie pour savoir si le scénario est suffisamment simple .
Résumer
- JuiceFS a obtenu les meilleurs résultats en termes de compatibilité et a réussi tous les éléments de test.
- Google Filestore était le suivant.Il y avait deux types d'échecs, dont l'un n'affectait pas l'utilisation réelle.
- Tencent Cloud CFS est similaire à Alibaba Cloud NAS, avec 7 à 8 éléments qui échouent tous les deux.
- HUAWEI CLOUD SFS, Amazon EFS et Azure File Shares ont une mauvaise compatibilité, et un grand nombre de tests de compatibilité ont échoué, y compris plusieurs cas de test avec de sérieux risques de sécurité. Il est recommandé de faire une évaluation de sécurité avant utilisation.
Si vous êtes utile, veuillez prêter attention à notre projet Juicedata/JuiceFS ! (0ᴗ0✿)