このトピックでは、ossfs の使用時によくある問題とそのソリューションについて説明します。問題が発生した場合は、まず ossfs のバージョンを確認してください。1.80.x などの古いバージョンを使用している場合は、最新バージョンにアップグレードしてください。新しいバージョンには、新機能と安定性の向上が含まれています。
一般情報
ossfs の各エラーにはメッセージが含まれています。問題をトラブルシューティングする際は、これらのメッセージを収集して問題の特定に役立ててください。たとえば、ソケット接続の失敗や HTTP 4xx または 5xx ステータスコードを受け取った場合は、トラブルシューティングを開始する前にデバッグログを有効にしてください。
403 エラーは、権限が不十分なためにアクセスが拒否されたことを示します。
400 エラーは、ユーザー操作が正しくないことを示します。
5xx エラーは、通常、ネットワークジッターまたはクライアント側のサービスの問題に関連しています。
ossfs の以下の特徴にご注意ください：
ossfs は、リモートの OSS バケットをローカルディスクにマウントします。ビジネスで高いファイル読み書き性能が必要な場合は、ossfs を使用しないでください。
ossfs の操作はアトミックではありません。オンプレミスでの操作は成功しても、リモートの OSS 操作は失敗する可能性があります。
ossfs がビジネス要件を満たさない場合は、ossutil の使用をご検討ください。
権限の問題
マウント成功後に touch コマンドを実行すると 403 エラーが発生する
原因：403 エラーは通常、アクセス権限が不十分なことが原因で発生します。以下の状況でファイルに対して `touch` を実行すると、403 エラーが発生する可能性があります：
ファイルがアーカイブストレージオブジェクトである場合。このファイルに対して `touch` コマンドを実行すると 403 エラーが返されます。
使用している AccessKey にバケットへのアクセスに必要な権限がない場合。
ソリューション：
アーカイブストレージオブジェクトの場合、アクセスする前にオブジェクトを解凍する必要があります。または、オブジェクトが保存されているバケットでアーカイブオブジェクトのリアルタイムアクセスを有効にすることもできます。
権限の問題については、AccessKey に関連付けられているアカウントに必要な権限を付与してください。
rm コマンドでファイルを削除しようとすると "Operation not permitted" エラーが発生する
原因：`rm` コマンドを実行してファイルを削除すると、`DeleteObject` API 操作が呼び出されます。Resource Access Management (RAM) ユーザーとしてバケットをマウントした場合、その RAM ユーザーにファイルを削除する権限があるか確認してください。
ソリューション：RAM ユーザーに必要な権限を付与します。詳細については、「RAM ポリシー」および「RAM ポリシーの一般的な例」をご参照ください。
"The bucket you are attempting to access must be addressed using the specified endpoint" エラーが発生する
原因：このメッセージは、エンドポイントが正しく指定されていないことを示します。このエラーは次の 2 つの理由で発生する可能性があります：
バケットとエンドポイントが一致しません。
バケットのオーナーの UID が、AccessKey に関連付けられているアカウントの UID と異なる。
ソリューション：構成が正しいことを確認し、必要に応じて変更してください。
マウントの問題
ossfs はバケットをマウントするためのカスタムドメイン名をサポートしていますか？
いいえ、ossfs は現在、カスタムドメイン名のシナリオをサポートしていません。
ossfs 1.91.7 以降で ECS RAM ロールを使用するとマウントに失敗する
ソリューション：
curl http://100.100.100.200/latest/meta-data/ram/security-credentials/[your-ecs-ram-role]コマンドを実行して接続性を確認します。`curl` コマンドが正常に実行された場合は、バケットをマウントする際に
-o disable_imdsv2オプションを追加します。
マウント中に "ossfs: unable to access MOUNTPOINT /tmp/ossfs: Transport endpoint is not connected" エラーが発生する
原因：このエラーは、マウントポイントのディレクトリが存在しないために発生します。
ソリューション：バケットをマウントする前に、マウントポイントのディレクトリを作成してください。
マウント中に "fusermount: failed to open current directory: Permission denied" エラーが発生する
原因：これは Filesystem in Userspace (FUSE) のバグです。現在のユーザーは、マウントディレクトリとは異なる現在の作業ディレクトリに対する読み取り権限を持っている必要があります。
ソリューション：`cd` コマンドを実行して読み取り権限のあるディレクトリに切り替えてから、`ossfs` コマンドを実行してください。
マウント中に "ossfs: Mountpoint directory /tmp/ossfs is not empty. if you are sure this is safe, can use the 'nonempty' mount option" エラーが発生する
原因：デフォルトでは、ossfs は空のディレクトリにのみマウントできます。このエラーは、空でないディレクトリにバケットをマウントしようとすると発生します。
ソリューション：空のディレクトリに切り替えて、再度バケットをマウントしてください。空でないディレクトリにバケットをマウントする必要がある場合は、マウントコマンドに `-ononempty` パラメーターを追加してください。
マウント中に "ops-nginx-12-32 s3fs[163588]: [tid-75593]curl.cpp:CurlProgress(532): timeout now: 1656407871, curl_times[curl]: 1656407810, readwrite_timeout: 60" エラーが発生する
原因：ossfs のマウント操作がタイムアウトしました。
ソリューション：ossfs は readwrite_timeout オプションを使用して、読み書きリクエストのタイムアウト期間を指定します。単位は秒で、デフォルト値は 60 です。必要に応じてこの値を増やすことができます。
マウント中に "ossfs: credentials file /etc/passwd-ossfs should not have others permissions" エラーが発生する
原因：/etc/passwd-ossfs ファイルの権限が正しくありません。
ソリューション：/etc/passwd-ossfs ファイルにはアクセス認証情報が保存されています。これらの認証情報を保護するため、他のユーザーがこのファイルにアクセスできないようにする必要があります。chmod 640 /etc/passwd-ossfs コマンドを実行して、ファイルのアクセス権限を変更してください。
マウント成功後にフォルダに対して ls コマンドを実行すると "operation not permitted" エラーが発生する
原因：このエラーは、バケットに名前が不可視文字を含むオブジェクトが含まれている場合に発生する可能性があります。ファイルシステムには、ファイル名とディレクトリ名に厳格な制限があります。
ソリューション：別のツールを使用してこれらのオブジェクトの名前を変更してください。名前を変更した後、`ls` コマンドでディレクトリの内容が正しく表示されるようになります。
マウント中に "fuse: device not found, try 'modprobe fuse'" エラーが発生する
原因：Docker コンテナー内で ossfs を使用してマウントしようとすると、"fuse: device not found, try 'modprobe fuse'" エラーが発生することがあります。このエラーは通常、コンテナーが FUSE カーネルモジュールへのアクセスまたはロードに必要な権限を持っていないことが原因です。
ソリューション：Docker コンテナーで ossfs を実行する場合、--privileged=true パラメーターを追加してコンテナーに高い権限を付与できます。これにより、コンテナー内のプロセスは、FUSE ファイルシステムの使用を含め、ホスト上と同様の操作を実行できます。以下は、--privileged フラグを使用してコンテナーを起動するコマンドの例です：
docker run --privileged=true -d your_imageマウント中に "ossfs: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file: No such file or directory" エラーが発生する
原因：インストールパッケージのバージョンがオペレーティングシステムのバージョンと一致していません。
ソリューション：この問題を解決するには、ご利用のオペレーティングシステムに対応するインストールパッケージをダウンロードしてください。
コストの問題
OSS を Elastic Compute Service (ECS) インスタンスにマウントした際に、バックグラウンドプログラムによるファイルスキャンで発生するコストを回避する方法
原因：プログラムが ossfs によってマウントされたディレクトリをスキャンすると、そのスキャンは OSS へのリクエストに変換されます。多くのリクエストが発生すると料金が発生する可能性があります。
ソリューション：`auditd` ツールを使用して、どのプロセスが OSS のマウントディレクトリをスキャンしているかを特定できます。手順は次のとおりです：
`auditd` をインストールして起動します。
sudo apt-get install auditd sudo service auditd startOSS のマウントディレクトリを監視対象のディレクトリとして設定します。たとえば、マウントディレクトリが /mnt/ossfs の場合：
auditctl -w /mnt/ossfs監査ログをチェックして、どのプロセスがこのディレクトリにアクセスしたかを特定します。
ausearch -i | grep /mnt/ossfsプログラムのパラメーターを変更してスキャンをスキップします。
たとえば、監査ログに updatedb がマウントディレクトリをスキャンしたことが示されている場合、/etc/updatedb.conf を変更してそのディレクトリをスキップできます。そのためには：
RUNEFS =の後にfuse.ossfsを追加します。マウントディレクトリを
PRUNEPATHS行に追加します。
ディスクとメモリの問題
ossfs が断続的に切断される
分析：
-d -odbglevel=dbg パラメーターを追加して ossfs のデバッグログを有効にします。ossfs はデフォルトのシステムログファイルにログを書き込みます。
CentOS システムの場合：ログは
/var/log/messagesに書き込まれます。Ubuntu システムの場合：ログは
/var/log/syslogに書き込まれます。
ログを分析します。ログには、ossfs が `listbucket` および `listobject` 操作で過剰なメモリを要求し、システムの Out-Of-Memory (OOM) Killer をトリガーしたことが示される場合があります。
説明`listobject` 操作は、オブジェクトのメタデータを取得するために OSS に HTTP リクエストを送信します。ファイルが多数ある場合、`ls` コマンドはメタデータを取得するために大量のシステムメモリを消費します。
ソリューション：
-omax_stat_cache_size=xxx パラメーターを使用して stat キャッシュのサイズを増やします。最初の `ls` 操作は遅くなりますが、オブジェクトのメタデータがローカルキャッシュに保存されるため、後続の `ls` 操作は速くなります。デフォルト値は 1,000 で、約 4 MB のメモリを消費します。この値は、マシンのメモリサイズに基づいて調整できます。
読み書き操作中、ossfs は Nginx のようにディスク領域を使用して大量の一時キャッシュデータを書き込みます。これにより、ディスクの空き領域が不足する可能性があります。ossfs が終了すると、これらの一時ファイルは自動的にクリーンアップされます。
ossfs の代わりに ossutil を使用します。ossfs は、パフォーマンスに敏感でない非本番サービスに使用できます。高い信頼性と安定性が要求されるサービスには、ossutil を使用してください。
ossfs がディスク領域を使い切るのはなぜですか？
原因：パフォーマンスを向上させるため、ossfs はデフォルトで可能な限り多くのディスク領域を使用して、アップロードとダウンロードのための一時データを保存します。これにより、ディスクがいっぱいになる可能性があります。
ソリューション：-oensure_diskfree オプションを使用して、予約するディスク領域の量を指定できます。たとえば、20 GB のディスク領域を予約するには、マウントコマンドにオプションを追加します：
ossfs examplebucket /tmp/ossfs -o url=http://oss-cn-hangzhou.aliyuncs.com -oensure_diskfree=20480ossfs でマウントした後、df コマンドでディスク領域が 256 TB と表示されるのはなぜですか？
df コマンドで表示されるディスク領域は表示目的のみであり、OSS バケットの実際の容量を表すものではありません。`Size` (合計ディスク領域) と `Avail` (空きディスク領域) の値は 256 TB に固定されています。`Used` (使用済みディスク領域) の値は 0 TB に固定されています。
OSS は無制限のバケット容量を提供します。バケットのストレージ使用量は、実際の使用状況によって異なります。バケットの使用量を照会する方法の詳細については、「バケットレベルの使用量の照会」をご参照ください。
cp コマンドを使用してデータをコピーすると "input/output error" が発生する
原因：システムディスクのエラーが検出されると、入出力エラーが報告されます。エラー発生時にディスクの読み書き負荷が高くなっていないか確認してください。
ソリューション：シャーディングパラメーターを追加して、ファイルの読み書きを制御できます。ossfs -h コマンドを実行して、利用可能なシャーディングパラメーターを表示してください。
rsync を使用して同期すると "input/output error" が発生する
原因：ossfs を `rsync` と 。このケースでは、ユーザーが 141 GB のファイルに対して `cp` コマンドを実行しました。これにより、ディスクは読み書き操作で高負荷状態になり、エラーが発生しました。
ソリューション：OSS からローカルの ECS インスタンスにファイルをダウンロードしたり、ローカルファイルを ECS インスタンスにアップロードしたりする場合は、ossutil のマルチパートアップロードまたはダウンロード機能を使用してください。
大きなファイルをアップロードすると "there is no enough disk space for used as cache(or temporary)" エラーが発生する
原因
利用可能なディスク領域が
multipart_size × parallel_count未満です。`multipart_size` はパートサイズを MB 単位で指定し、`parallel_count` は同時アップロードパート数を指定します。`parallel_count` のデフォルト値は 5 です。
分析
デフォルトでは、ossfs は大きなファイルをアップロードするためにマルチパートアップロードを使用します。アップロード中、ossfs は一時キャッシュファイルを /tmp フォルダに書き込みます。書き込む前に、ossfs は /tmp フォルダを含むディスクの空き領域が
multipart_size × parallel_count未満であるかどうかを確認します。ディスクの空き領域がmultipart_size × parallel_countより大きい場合、ファイルは正常に書き込まれます。ディスクの空き領域がmultipart_size × parallel_count未満の場合、ローカルディスク領域が不足していることを示すエラーが返されます。たとえば、ディスクの空き領域が 300 GB で、アップロードするファイルが 200 GB であるとします。しかし、`multipart_size` が 100000 (100 GB) に設定され、同時アップロードパート数がデフォルト値の 5 のままである場合、ossfs は必要なアップロード領域が 100 GB × 5 = 500 GB であると判断し、これは利用可能なローカルディスク領域を超えています。
ソリューション
同時アップロードパート数をデフォルト値の 5 のままにする場合、`multipart_size` を適切な値に設定してください：
ディスクの空き領域が 300 GB で、アップロードするファイルが 200 GB の場合、`multipart_size` を 20 に設定します。
ディスクの空き領域が 300 GB で、アップロードするファイルが 500 GB の場合、`multipart_size` を 50 に設定します。
依存関係に関する問題
ossfs のインストール中に "fuse: warning: library too old, some operations may not work" エラーが発生する
原因：このエラーは、ossfs のコンパイル時に使用された `libfuse` のバージョンが、ランタイム時にリンクされる `libfuse` のバージョンよりも新しいために発生します。これは、ユーザーが `libfuse` を手動でインストールした場合によく発生します。CentOS 5.x および CentOS 6.x システムでは、Alibaba Cloud が提供する ossfs インストールパッケージには `libfuse-2.8.4` が含まれています。ランタイム環境に `libfuse-2.8.3` が存在し、ossfs が古いバージョンの FUSE にリンクされている場合、このエラーが発生します。
ldd $(which ossfs) | grep fuse コマンドを実行して、ossfs がランタイム時にリンクする FUSE のバージョンを確認できます。結果が /lib64/libfuse.so.2 の場合、ls -l /lib64/libfuse* コマンドを実行して FUSE のバージョンを確認できます。
ソリューション：ossfs を正しいバージョンにリンクします。
rpm -ql ossfs | grep fuse コマンドを実行して `libfuse` ディレクトリを見つけます。
結果が /usr/lib/libfuse.so.2 の場合、LD_LIBRARY_PATH=/usr/lib ossfs … コマンドで ossfs を実行します。
fuse 依存関係ライブラリをインストールするとエラーが発生する
原因：FUSE のバージョンが ossfs の要件を満たしていません。
ソリューション：最新バージョンの FUSE を手動でダウンロードしてインストールしてください。インストールに `yum` を使用しないでください。詳細については、fuse をご参照ください。
ls を使用してファイルをリストすると "Input/Output error" が発生する
原因：この問題は主に CentOS 環境で発生します。ログには NSS error -8023 が報告されます。ossfs が HTTPS 通信に `libcurl` を使用する際に問題が発生します。これは、`libcurl` が依存する Network Security Services (NSS) ライブラリのバージョンが低すぎるためである可能性があります。
ソリューション：次のコマンドを実行して、NSS ライブラリを最新バージョンにアップグレードしてください。
yum update nssyum/apt-get を使用して ossfs をインストールすると "conflicts with file from package fuse-devel" エラーが発生する
原因：システムに古いバージョンの FUSE が存在し、ossfs の依存関係バージョンと競合しています。
ソリューション：まず、関連するパッケージマネージャーを使用して FUSE をアンインストールし、その後 ossfs を再インストールしてください。
その他の問題
OSS ファイルが多数ある場合や高同時実行性シナリオで ossfs を使用してマウントした後に遅延が発生する場合の推奨事項
ossfs 1.0 は高同時実行性シナリオでの使用は推奨されません。そのようなシナリオで使用する必要がある場合は、次のソリューションを検討してください：
ソリューション 1：ossfs 2.0 でマウントする。ossfs 1.0 と比較して、ossfs 2.0 はシーケンシャルな読み書き、および高同時実行性での小規模ファイルの読み取りにおいて大幅なパフォーマンス向上を提供します。ossfs 2.0 のパフォーマンスの詳細については、「パフォーマンスの向上」セクションをご参照ください。
ソリューション 2：パフォーマンス向上のために Cloud Storage Gateway を使用して OSS をマウントする。ossfs 1.0 ツールは、大規模ファイルの同時実行性の高いアップロードおよびダウンロードには推奨されません。小規模ファイルの日常的な操作に適しています。
ossfs を使用して OSS にアップロードされたファイルの Content-Type が常に application/octet-stream になる
原因：ファイルをアップロードする際、ossfs は /etc/mime.types の内容を照会してファイルの `Content-Type` を設定します。このファイルが存在しない場合、`Content-Type` はデフォルトで `application/octet-stream` に設定されます。
ソリューション：このファイルが存在するかどうかを確認してください。存在しない場合は、追加する必要があります。
コマンドを使用して mime.types ファイルを自動的に追加する
Ubuntu システム
sudo apt-get install mime-support コマンドを実行してファイルを追加します。
CentOS システム
sudo yum install mailcap コマンドを実行してファイルを追加します。
mime.types ファイルを手動で追加する
mime.types ファイルを作成します。
vi /etc/mime.types必要なフォーマットを追加します。各フォーマットは新しい行に、
application/javascript jsの形式で記述します。
ファイルを追加した後、OSS バケットを再マウントする必要があります。
ossfs がフォルダを通常のファイルとして識別するのはなぜですか？
シナリオ 1：
原因：フォルダオブジェクト (名前が
/で終わるオブジェクト) を作成し、`Content-Type` を `text/plain` として指定すると、ossfs はこのオブジェクトを通常のファイルとして識別します。ソリューション：マウント時に `-ocomplement_stat` パラメーターを追加できます。フォルダオブジェクトのサイズが 0 または 1 の場合、ossfs はそれをディレクトリとして識別します。
シナリオ 2：
原因：
ossutil stat folder_object/コマンド (例：ossutil stat oss://[bucket]/folder/) を実行できます。コマンドを実行した後：オブジェクトの `Content-Length` フィールド (オブジェクトサイズ) を確認します。オブジェクトサイズが 0 でない場合、オブジェクトはファイルとして識別されます。
ソリューション：フォルダオブジェクトの内容が不要になった場合は、
ossutil rm oss://[bucket]/folder/コマンドを実行してオブジェクトを削除できます。これはディレクトリ以下のファイルには影響しません。または、同じ名前の 0 バイトオブジェクトをアップロードして上書きすることもできます。オブジェクトサイズが 0 の場合は、`Content-Type` フィールド (オブジェクト属性) を確認します。`Content-Type` が
application/x-directory、httpd/unix-directory、binary/octet-stream、またはapplication/octet-streamでない場合、オブジェクトはファイルとしても識別されます。ソリューション：
ossutil rm oss://[bucket]/folder/コマンドを実行してオブジェクトを削除できます。これはディレクトリ以下のファイルには影響しません。
ossfs で mv 操作が失敗する
原因：ossfs での `mv` 操作は、ソースファイルがアーカイブ、コールドアーカイブ、またはディープコールドアーカイブオブジェクトであるために失敗する可能性があります。
ソリューション：アーカイブ、コールドアーカイブ、またはディープコールドアーカイブオブジェクトに対して `mv` コマンドを実行する前に、オブジェクトを解凍する必要があります。詳細については、「オブジェクトの解凍」をご参照ください。
ossfs は Windows 環境でのバケットのマウントをサポートしていますか？
いいえ、サポートしていません。Rclone を使用して Windows にバケットをマウントできます。詳細については、「Rclone」をご参照ください。
ossfs は OSS バケットを複数の Linux ECS サーバーにマウントすることをサポートしていますか？
はい、サポートしています。バケットを複数の Linux ECS サーバーにマウントできます。詳細については、「バケットのマウント」をご参照ください。
ossfs で表示されるファイル情報 (サイズなど) が他のツールで表示される情報と一致しないのはなぜですか？
原因：デフォルトでは、ossfs はサイズや権限などのファイルメタデータをキャッシュします。このキャッシュは、毎回 OSS にリクエストを送信するのを避けることで `ls` 操作を高速化します。ユーザーが SDK、OSS コンソール、ossutil などの別のプログラムを使用してファイルを変更した場合、ossfs はキャッシュをすぐには更新しません。これにより、ファイル情報が他のツールで表示される情報と一致しなくなります。
ソリューション：マウント時に -omax_stat_cache_size=0 パラメーターを追加して、メタデータキャッシュ機能を無効にすることができます。キャッシュが無効になっている場合、`ls` を実行するたびに、最新のファイル情報を取得するために OSS にリクエストが送信されます。
バケットでバージョン管理を有効にすると、マウントが遅くなるのはなぜですか？
原因：デフォルトでは、ossfs は ListObjects (GetBucket) 操作を呼び出してファイルをリストします。バケットでバージョン管理が有効になっており、バケットに 1 つ以上の以前のバージョンのオブジェクトと多数の期限切れの削除マーカーが含まれている場合、現在のオブジェクトバージョンをリストする際の ListObjects (GetBucket) 操作の応答速度が低下します。これにより、ossfs のマウント操作が遅くなります。
ソリューション：-olistobjectsV2 オプションを使用して ossfs を構成し、ListObjectsV2 (GetBucketV2) 操作を使用してファイルリストのパフォーマンスを向上させます。
HTTPS 経由でバケットをマウントするにはどうすればよいですか？
ossfs は HTTPS 経由でのマウントをサポートしています。以下は、中国 (杭州) リージョンのコマンド例です：
ossfs examplebucket /tmp/ossfs -o url=https://oss-cn-hangzhou.aliyuncs.comフォルダに非常に多数のファイルが含まれている場合に ls コマンドが遅くなるのはなぜですか？
原因：ディレクトリに N 個のファイルが含まれている場合、そのディレクトリに対する `ls` コマンドは、OSS に対して少なくとも N 回の HTTP リクエストを必要とします。ディレクトリに非常に多数のファイルが含まれている場合、これは深刻なパフォーマンス問題を引き起こす可能性があります。
ソリューション：-omax_stat_cache_size=xxx パラメーターを使用して stat キャッシュのサイズを増やします。最初の `ls` 操作は遅くなりますが、オブジェクトのメタデータがローカルキャッシュに保存されるため、後続の `ls` 操作は速くなります。バージョン 1.91.1 より前は、デフォルト値は 1,000 でした。バージョン 1.91.1 からは、デフォルト値は 100,000 で、数十メガバイトのメモリを使用します。この値は、マシンのメモリに基づいて調整できます。
アンマウント中に "fusermount: failed to unmount /mnt/ossfs-bucket: Device or resource busy" エラーが発生する
原因：プロセスがマウントされたディレクトリ /mnt/ossfs-bucket 内のファイルにアクセスしているため、ディレクトリをアンマウントできません。
ソリューション：
lsof /mnt/ossfs-bucketを実行して、ディレクトリにアクセスしているプロセスを見つけます。`kill` コマンドを実行して、プロセスを強制的に終了させます。
fusermount -u /mnt/ossfs-bucketを実行してバケットをアンマウントします。
ossfs 1.0 を使用すると 404 ログが多数表示される
背景：ossfs 1.0 を使用すると、ログに 404 Not Found レコードがよく表示されます。ほとんどの場合、これはシステムエラーではなく、ossfs 1.0 がローカルファイルシステムのセマンティクスをシミュレートするために使用する通常の対話的な動作です。
ファイルを操作する前に、オペレーティングシステムはターゲットオブジェクトが存在するかどうかを確認します。このプロセスにより、多数のプローブ要求が OSS に送信される可能性があります。オブジェクトが存在しない場合、OSS は 404 ステータスコードを返します。
ossfs 1.0 がオブジェクトの存在を確認する完全なプロセスは次のとおりです：
`HeadObject` リクエストを送信して、
objectなどの指定されたパスが実際のオブジェクトとして存在するかどうかを照会します。オブジェクトが存在する場合、OSS はオブジェクトのメタデータを返します。オブジェクトが存在しない場合、OSS は 404 エラーを返し、ossfs は次のステップに進みます。
404 エラーを受け取った後、ossfs は `HeadObject` リクエストを送信して、
object/オブジェクトが存在するかどうかを照会します。オブジェクトが存在する場合、OSS はオブジェクトのメタデータを返します。オブジェクトが存在しない場合、OSS は 404 エラーを返し、ossfs は次のステップに進みます。
404 エラーを受け取った後、ossfs は `HeadObject` リクエストを送信して、
object_$folder$オブジェクトが存在するかどうかを照会します。オブジェクトが存在する場合、OSS はオブジェクトのメタデータを返します。オブジェクトが存在しない場合、OSS は 404 エラーを返し、ossfs は次のステップに進みます。
404 エラーを受け取った後、ossfs は `ListObjects` リクエストを送信して、プレフィックス
object/を持つオブジェクトを照会することにより、指定されたパスが「ディレクトリ」であるかどうかを判断します。結果が空の場合、パスは存在しないと判断されます。結果が空でない場合、ディレクトリは存在し、システムはディレクトリの内容をリストします。
分析：
`stat` などのコマンドを使用して存在しないファイルにアクセスすると、OSS は 404 エラーを返し、これはローカルファイルシステムの "No such file or directory" エラーにマッピングされます。
バッチでファイルやディレクトリを作成する前に、オペレーティングシステムはまずターゲットファイルが存在するかどうかを確認します。ファイルが存在しない場合にのみ作成リクエストを送信します。この確認中に生成される 404 エラーは、システム例外ではなく、予期される動作です。
ソリューション：404 エラーは通常の動作ですが、頻繁なプローブ要求は、高同時実行性またはバッチ操作のシナリオでパフォーマンスに影響を与える可能性があります。次の方法で構成を最適化できます：
これらのオプションを構成した後、ossfs 1.0 はローカルキャッシュの有効期限が切れるまで、OSS 上のファイルに加えられた変更を検出できません。
-o stat_cache_expireと-o max_stat_cache_sizeの値を増やすことで、メタデータキャッシュの期間とキャッシュされるエントリ数を増やします。メタデータの有効期限が切れる前にファイルまたはディレクトリを照会することで、OSS への繰り返しリクエストを回避できます。
-o stat_cache_expire：メタデータキャッシュの有効期限 (秒単位)。デフォルト値は 900 です。-o max_stat_cache_size：メタデータキャッシュのエントリ数。デフォルト値は 100,000 です。
1.91.6 より前のバージョンの ossfs を使用している場合は、
-o enable_noobj_cacheを構成してネガティブキャッシュを有効にします。ネガティブキャッシュは ossfs 1.91.6 以降ではデフォルトで有効になっています。ファイルが初めて照会されて存在しない場合、その結果はメモリにキャッシュされます。キャッシュの有効期限が切れる前にそのファイルを再度照会すると、OSS リクエストを送信する代わりにローカルのネガティブキャッシュを直接照会します。
説明ossfs 1.0 のファイルネガティブキャッシュはメタデータキャッシュの一部です。有効期限は
-o stat_cache_expireパラメーターで制御され、キャッシュされるエントリの最大数は-o max_stat_cache_sizeパラメーターで制御されます。