ウェブサービスの多数のユーザーに対して、ファイルの作成/読み取り/書き込み/削除とクォータの設定を行う機能を提供する必要があります。これらのユーザーは Linux ユーザーとして存在しないため、クォータを適用できません。クォータを実行するためだけに実際のユーザーを作成するのは、あまり良い考えではないようです。そのため、ユーザーごとのファイルを作成し、それをファイルシステムとしてマウントすることにしました。
- 数万台のFSをマウントするとどうなるでしょうか？
- マウントされる FS の総数に制限はありますか?
答え1
まず、これほど多くのファイルシステムをマウントするのは本当に悪い考えのように思えます。どのような問題であっても、もっと良い解決策があるはずです。
とにかく、2番目の質問に答えると、以前のサーバー障害の質問最近のカーネルでは、ファイルシステムの種類ごとに約 100 万のマウント ポイント (2^20) に制限されており、最大 256 種類のファイルシステムをマウントできるようです。
古いカーネル (2.6 より前) の場合、制限はファイルシステムあたり 256 マウント ポイントです。
編集コメントに応えて、私は次の代替解決策を提案します。
XFSを使用すると、プロジェクト割り当てディレクトリ クォータの一種。
すべての Web サービス ユーザー データを保持する別の XFS ファイル システムを作成します。 これを などにマウントします/mnt/myWebService。 次に、各 Web サービス ユーザーに対してプロジェクト ディレクトリ (など/mnt/myWebService/username1) を作成し、それに応じてクォータを設定します。
プロジェクトディレクトリとクォータの設定方法については、例えば以下を参照してください。このブログ記事またはRHEL XFS クォータ管理ページ
答え2
ユーザーを作成する必要はありません (/etc/passwd または任意のユーザー データベースに追加するなど)。作成しなくても、ファイルの所有権を任意の uid に設定できます。ただし、それらの uid が、そのサーバー上でプロセスを実行する可能性のあるローカル (またはリモート) ユーザーと重複していないことを確認してください。
ただし、ファイルの所有者を変更するにはスーパーユーザー権限が必要であり、Web アプリケーションでは問題が発生する可能性があります。
ZFS を使用する場合、スナップショットごとに 1 つのマウント ポイントが作成されますが、数千のマウント ポイントが存在することも珍しくなく、それほど大きな問題にはなりません。
答え3
このために無数のファイルシステムを作成する必要はありません。
これを行う簡単な方法は、各ユーザー用のディレクトリを作成し (これは既に行う必要があります)、ユーザーが何かをアップロードしようとするたびに、ディレクトリ内のファイルが使用する容量を確認することです。アップロードによって制限を超える場合は、アップロードを拒否します。これは、既知の宇宙にある他のすべての Web アプリケーションで行われている方法です。
PS: あなたが行っていることの詳細が複数のコメントに散りばめられています。代わりに質問に詳細を追加して、人々が見つけられるようにしてください (そしておそらくあなたのダウン投票を取り消してください)。