2025年 10月 21日
ファイルサーバーに容量制限、XFS パーティションのディレクトリ・クオータ:ファイルサーバーはファイルのごみ箱じゃない!
ファイルサーバーはファイルのごみ箱じゃない!
Linux システムで Samba を動かし、ファイルサーバーとして利用することは、非常にコストが低く済む、良い選択の一つです。しかし、よく管理されて運用されるのならともかく、管理が上手くいってないと、ファイルサーバーは、使われる機会のない古いファイルのゴミ箱になってしまう可能性があります。

そこで、共有ファイルサーバーには、厳しく容量制限を設定して、きめ細かく必要なファイルだけを保存するなり、古いファイルはアーカイブとして、別なメディアに保管するなりの整理するように運用しましょうというご提案です。ということで、Linux + Samba 環境でファイルサーバーを運用する場合、考えておきたい容量管理、クォータ制限について考えてみました。
容量管理は、ユーザ毎、グループ毎で管理するのが一般的です。しかし、現実的にはグループやユーザ単位でディレクトリ、フォルダへのアクセス管理を行うわけですから、ユーザがアクセスできるフォルダというのは決まっているのが普通です。共有サーバーの中は、たっぷりデータ・エントリーを作ってせっせとユーザクォータを使い続けるユーザも居れば、そうして出来上がった成果をリードオンリーで参照するユーザ、あるいは全ユーザ共有のリードオンリーのフォルダなどがあるわけです。実際に運用してみると、ユーザクォータやグループクォータはあまり意味がありません。
ユーザのホームディレクトリに容量制限をかけるのは最低限現実的ですが、ファイルサーバーとは、組織の中で共有のデータを管理するためのものですから、ユーザクォータというのは意外と意味をなさない。
それよりも、プロジェクト・グループ毎に分け与えられたフォルダに利用制限をかけた方がよほど効果的なのです。総務部は1Tバイト、営業部は3Tバイトと言った感じですね。
Windows Server に比べて Linux でファイルサーバーを使うということで、圧倒的なコスト削減を達成することができます。費用というのは絶対的な選択理由ですね。Windows + AD で構成されるファイルサーバーの場合、ユーザ管理と一様にアクセス管理ができるメリットがありますが、AD 全体のセキュリティポリシーで運用されるため、管理の複雑さが作り出す脆弱性の原因になります。最近よく聞くランサムウェア被害は Windows Server が踏み台になることが多いよううです。
Windows とは関係しない独立したシステムとして Linux + Samba を管理することで、 Windows とは切り離したシステムポリシーで運用できます。一網打尽的なマルウェア、ランサムウェア被害から逃れることができる? でしょう。
また、ファイルサーバーという単純なしくみを複雑に操作しなければならない Windows Server に比べて Linux + Samba の方がパフォーマンスは高いので、これも有利です。
XFS パーティションでのクォータ管理Linux では Ext4、 BtrFS、XFS などのファイル・システムが使われますが、ディレクトリでのクォータ制限を使う場合、XFS クォータを使うのが一番有利なようです。 ext4 の場合、枯れた技術でパフォーマンスや信頼性は高いのですが、クォータ機能そのものが「後付」なので複雑です。 BtrFS は CoW 形式のファイル管理で、ファイルサーバーとして使うならファイルのロールバックやバックグラウンドでのファイル・システムのチェックなどシステム運用と可用性の機能に優れている反面、ロールバックを作る負荷や信頼性の面で不利で、サブボリューム単位で管理することになります。また、空き容量が正確に測定できないといった決定的なデメリットがあります。XFS パーティションで Samba を運用するのであれば、xfs クォータは Linux カーネルに近い部分で制御されるため、高速で比較的安定して容量管理ができるようです。openSUSE Leap15 では、ルートパーティションは BtrFS で、データパーティションは XFS がデフォルトです。XFS クォータ管理はユーザ、グループ、プロジェクトという3つのレベルで利用できます。ここでは、ユーザとグループで利用する共有領域、フォルダ./ディレクトリ単位で容量管理を行うことを目的として、プロジェクト単位での容量管理の方法について説明します。
ここでは、"/xfspart" というディレクトリに XFS でフォーマットしたパーテイションをマウントして、このディレクトリに容量制限をかけてみます。
ディレクトリ : "/xfspart"プロジェクト名 : "xfspart"プロジェクト ID : 10制限容量 : 5Gb
/etc/fstab に xfs パーティションで pquota のためのオプションを追加してマウント
opensuse15:~ # vi /etc/fstabopensuse15:~ # cat /etc/fstab | grep xfsUUID=2eecc895-a35c-4c59-bd35-48666cea48c2 /xfspart xfs defaults,pquota 0 0opensuse15:~ # mount -o remount /xfspartopensuse15:~ # mount | grep /xfspart/dev/vdb on /xfspart type xfs (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,prjquota)opensuse15:~ #

/etc/projects にプロジェクトを登録(project ID:10 "/xfspart" ディレクトリ)
opensuse15:~ # echo "10:/xfspart" | sudo tee -a /etc/projects
10:/xfspart
opensuse15:~ # cat /etc/projects
10:/xfspartopensuse15:~ #
/etc/projid にプロジェクトを登録
opensuse15:~ # echo "xfspart:10" | sudo tee -a /etc/projid
xfspart:10
opensuse15:~ # cat /etc/projid
xfspart:10
opensuse15:~ #
xfs_qoota コマンドで有効化
opensuse15:~ # xfs_quota -x -c "project -s xfspart" /xfspartSetting up project xfspart (path /xfspart)...Processed 1 (/etc/projects and cmdline) paths for project xfspart with recursion depth infinite (-1).opensuse15:~ #opensuse15:~ # xfs_quota -x -c 'limit -p bsoft=5G bhard=5G xfspart' /xfspartopensuse15:~ #opensuse15:~ # xfs_quota -x -c "report -p" /xfspartProject quota on /xfspart (/dev/vdb)BlocksProject ID Used Soft Hard Warn/Grace---------- --------------------------------------------------#0 0 0 0 00 [--------]xfspart 4504 5242880 5242880 00 [--------]opensuse15:~ #
確認
実際に、Samba クライアントから、ディレクトリ(フォルダ)に容量制限がかかっているかを確認してみる。

他のホストから大きなファイルをコピーしてみます。
opensuse15:/xfspart # xfs_quota -x -c "report -p" /xfspart
Project quota on /xfspart (/dev/vdb)
Blocks
Project ID Used Soft Hard Warn/Grace
---------- --------------------------------------------------
#0 0 0 0 00 [--------]xfspart 4100504 5242880 5242880 00 [--------]opensuse15:/xfspart # scp root@192.168.1.240:/tmp/dvd.iso /xfspart/dvd2.iso(root@192.168.1.240) Password:dvd.iso 27% 1118MB 31.6MB/s 01:31 ETAscp: write local "/xfspart/dvd2.iso": No space left on deviceopensuse15:/xfspart #
ディレクトリ単位で容量制限をすることができました。
AI 搭載可能な化け物 CPU 搭載可能 | |



