7つのクラウド共有ファイルシステムのPOSIX互換性コンテスト

ユーザーがファイル システムを選択する場合、POSIX セマンティック互換性は不可欠な指標です。JuiceFS は、常に POSIX 標準との高い互換性を重視しており、機能とパフォーマンスを継続的に改善しながら、最大限の POSIX 互換性を維持するために最善を尽くしてきました。

最近、POSIX 互換性に関して、ユーザーがこれらの主流ファイルの互換性パフォーマンスを理解できるように、Tencent Cloud CFS、Alibaba Cloud NAS、Huawei Cloud SFS、GCP Filestore、Amazon EFS、Azure ファイル共有、および JuiceFS でテストを実施しました。システム。

POSIXとは、Portable Operating System Interface(Portable Operating System Interface)の略で、簡単に言えば、ファイルストレージをはじめとするファイルストレージの分野で最も広く使われているオペレーティングシステムのインターフェース仕様です。POSIX 標準の詳細については、Quora の質問と回答「分散システムの世界での POSIX 準拠/準拠とは?」を参照してください。

試験方法

ファイル システムの POSIX 互換性をテストするための一般的なテスト ケース セットはpjdfstestです。これは FreeBSD に由来し、Linux などのシステムにも適用できます。

試験結果

テスト結果は上の図に示されています。JuiceFS は失敗例が 0 であり、最高の互換性を示しています。GCP Filestore に続いて、Huawei Cloud SFS、Amazon EFS、および Azure File 共有の 2 つの失敗があり、他の製品よりも桁違いに大きいテスト ケースに失敗しました。比較の便宜上、上の図の横座標は対数座標を使用しています。

失敗事例分析

HUAWEI CLOUD SFS、Amazon EFS、Azure ファイル共有の失敗事例は、他のファイル システムに比べて総数とカテゴリの点ではるかに多いため、同じチャートで比較することはできず、後で個別に分析します。

GCP ファイルストア

GCP Filestore は、カテゴリ unlink と utimesat でそれぞれ 1 つずつ、合計 2 つのテストに失敗しました。

最初の項目はunlink テスト セットのunlink/14.tで、対応するログは次のとおりです。

/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

このテスト スイート ( unlink/14.t ) は、開いている間に削除されるファイルの動作を確認するために使用されます。

desc="An open file will not be immediately freed by unlink"

ファイルを削除する操作は、実際にはシステム レベルでの unlink、つまり、ファイル名から対応する inode へのリンクを削除し、対応する nlink 値を 1 減らすことに相当します。このテスト ケースは、この点を検証するものです。

# A deleted file's link count should be 0
expect 0 open ${n0} O_RDONLY : unlink ${n0} : fstat 0 nlink

ファイルの内容が実際に削除されるのは、リンク数 (nlink) が 0 に減り、そのファイルを指すオープン ファイル記述子 (fd) がない場合のみです。nlink が適切に更新されない場合、削除されるべきファイルがシステムに残る可能性があります。

もう 1 つの項目は、 utimesat テスト セットのutimesat/09.tであり、対応するログは次のとおりです。

/root/pjdfstest/tests/utimensat/09.t ........
not ok 5 - tried 'lstat pjdfstest_909f188e5492d41a12208f02402f8df6 mtime', expected 4294967296, got 4294967295

このテスト ケースでは、64 ビット タイムスタンプのサポートが必要です。GCP Filestore は 64 ビット タイムスタンプをサポートしていますが、これに基づいて 1 減少するため、このテスト ケースでは失敗しますが、使用には影響しないはずです

テンセント クラウド CFS

Tencent Cloud CFS は、utimesat、symlink、および unlink の 3 つのカテゴリで 7 つの項目に失敗しました。分析と説明のためにいくつかの重要な失敗項目を選択しました。

symlink の失敗ケースに対応するテスト ログは次のとおりです。

/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

このテスト セット ( symlink/03.t ) は、パスが PATH_MAX の長さを超えた場合の symblink の動作をテストするために使用されます。

desc="symlink returns ENAMETOOLONG if an entire length of either path name exceeded {PATH_MAX} characters"

失敗したユース ケースの対応するコードは次のとおりです。

n0=`namegen`nx=`dirgen_max`nxx="${nx}x"
mkdir -p "${nx%/*}"
expect 0 symlink ${nx} ${n0}
expect 0 unlink ${n0}

PATH_MAXこのテスト ケースは、長さ (末尾の 0 を含む) のシンボリック リンクPATH_MAX作成することですが、Tencent Cloud NAS で長さのシンボリック リンクを作成できないことを示していません。

アリババ クラウド NAS

Alibaba Cloud NAS は、chmod、utimesat、unlink でいくつかのテスト ケースに失敗しました。

chmod chmod/12.tのテスト セットでは、Alibaba Cloud NAS は次の項目で失敗しました。

/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

このテスト セット ( chmod/12.t ) は、SUID/SGID ビットの動作をテストするために使用されます。

desc="verify SUID/SGID bit behaviour"

11 番目と 12 番目のテスト ケースを選択して詳細に説明し、これら 2 つの許可ビットを同時にカバーします。

# 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}

ここでは、まず 06777 の権限で対象ファイルを作成し、ファイルの内容を変更して、SUID と SGID が正しくクリアされているかどうかを確認します。ファイルパーミッションの 777 はおなじみで、所有者、グループ、その他の rwx に対応し、読み取り、書き込み、実行可能を意味します。先頭の 0 は 8 進数を示します。

このオクテット (octet) は特別な許可ビットを表し、最初の 2 桁は setuid/setgid (または SUID/SGID) に対応し、実行可能ファイルとパブリック ディレクトリに適用できます。この許可ビットが設定されている場合、すべてのユーザーが所有者 (またはグループ) としてファイルを実行します。この特別な属性により、通常は所有者だけが利用できるファイルやディレクトリにユーザーがアクセスできるようになります。たとえば、passwd コマンドは setuid 権限を設定します。これにより、通常のユーザーがパスワードを変更できるようになります。これは、パスワードを保存するファイルは root だけがアクセスでき、ユーザーは直接変更できないためです。

setuid/setgid の設計の出発点は、制限されたファイル (現在のユーザーが所有していないファイル) に制限された方法 (実行可能ファイルの指定) でユーザーがアクセスできるようにすることです。したがって、ファイルが所有者以外によって変更された場合、ユーザーがこの方法で他のアクセス許可を取得できないように、このアクセス許可ビットを自動的にクリアする必要があります。

テスト結果から、Alibaba Cloud NASでは、ファイルが所有者以外によって変更された場合、setuid/setgid がクリアされないため、ユーザーはファイルを変更することで実際に所有者として任意の操作を実行できることがわかります問題となる内容です

詳細情報:特別なファイル許可(setuid、setgid、および Sticky Bit) (Solaris のシステム管理: セキュリティ サービス)

ファーウェイ クラウド SFS と Amazon EFS

HUAWEI CLOUD SFS と Amazon Elastic File System (EFS) は、pjdfstest テストで同様に失敗しました。故障率は約21%で、故障事例はほぼすべてのカテゴリをカバーしています。

どちらも NFS マウントをサポートしていますが、NFS 機能のサポートは不完全です。たとえば、ブロック デバイスとキャラクター デバイスはサポートされていません。これは、pjdfstest で多数のテスト ケースの失敗に直結します。これら 2 種類のファイルを除外した後でも、何百もの異なる種類のエラーが存在するため、複雑なシナリオでは注意して使用する必要があります

Azure ファイル共有

Azure ファイル共有の失敗率は 62% に達しました。これは、いくつかの基本的な POSIX シナリオに非互換性の問題がある可能性があることを示しています。たとえば、Azure ファイル共有のファイルとフォルダーの既定のアクセス許可は 0777、所有者は root、変更はサポートされていません。つまり、アクセス許可の制限はありません。さらに、Azure ファイル共有は、ハード リンクとシンボリック リンクをサポートしていません。そのため、Azure ファイル共有を使用するには、慎重にテストし、シナリオが十分に単純かどうかを慎重に検討する必要があります

要約する

  • JuiceFS は互換性の点で最高のパフォーマンスを発揮し、すべてのテスト項目に合格しました。
  • 次は Google Filestore で、2 種類の障害がありましたが、そのうちの 1 つは実際の使用には影響しませんでした。
  • Tencent Cloud CFS は Alibaba Cloud NAS に似ており、7 ~ 8 個のアイテムが両方とも失敗しています。
  • HUAWEI CLOUD SFS、Amazon EFS、Azure File Sharesは互換性が低く、セキュリティ上のリスクが深刻なテストケースを含む多数の互換性テストが失敗しているため、使用前にセキュリティ評価を行うことをお勧めします。

お役に立てれば、私たちのプロジェクトJuicedata/JuiceFSに注目してください! (0ᴗ0✿)

{{o.name}}
{{m.name}}

おすすめ

転載: my.oschina.net/u/5389802/blog/5585535