結論：ZimaOSの共有設定でアクセスは制御できるが、現行UIにはフォルダーごとの固定容量上限が記載されていない
要件はシンプルでした。各従業員に1つのプライベートフォルダーを割り当て、容量を4 TBに制限することです。ZimaOSのアカウントや共有権限では、フォルダーを「誰が」見られるかを制御できますが、現行の公開ドキュメントには「この共有フォルダーは最大X TBまで使用可能」とする標準機能は記載されていません。アクセス制御とストレージクォータは別の機能です。
厳密な容量制限には、ユーザーストレージを管理するアプリケーションを使用する
このようなマルチユーザー要件には、Nextcloudが最も適しています。現行の管理者マニュアルでは、5 TBなどのカスタム値を含む、ユーザーごとのクォータを設定できます。詳しくはNextcloudのユーザークォータに関するドキュメントをご覧ください。
Nextcloudのハードウェアガイドでは、データベースやアプリケーション用のストレージと、従業員用ファイルプールを分けて容量計画できます。フォルダー権限だけが必要で、クォータが不要な場合は、ZimaOSのSMB権限ガイドのほうが適しています。
アレイの速度低下はクォータの問題ではなかった
RAIDは単に再構築中でした。空のRAIDであっても、メンバーディスク間でブロックを再同期する必要があるため、CPU使用率が低いからといってストレージ処理が完了しているわけではありません。現行のZimaOS RAIDガイドでも、アレイの初期化中はパリティ処理や再構築処理によってストレージ性能が低下する可能性があると説明されています。
ベンチマークやデータ移行の前に再構築状態を確認する
cat /proc/mdstat
sudo mdadm --detail /dev/md0mdadmマニュアルは、アレイの状態を確認するための上流リファレンスです。再同期が100%に達するまでは、通常の転送速度を判断しないでください。
推奨される従業員用ストレージ構成
- プライベートフォルダーだけが必要：ZimaOSのユーザーとSMB権限。
- ユーザーごとの容量上限が必要：Nextcloudのユーザーとクォータ。
- ファイルシステムレベルのクォータが必要：高度なLinuxツール。ただし、ZimaOSのUIがその設定を管理したり、アップデート後も保持したりすると想定しないでください。
これにより、クォータの仕組みを、ユーザーアカウントのストレージモデルを実際に管理しているレイヤーに配置できます。
