LinuxでZFSを実行しているSambaサーバーがあります。
- これはマニュアルに準拠した標準インストールであり、特別な構成はありません。
- 各共有は独自の ZFS データセットにマッピングされますが、すべてのデータセットが独自の共有を持つわけではありません。
Oracle Linux 9.2
ZFS 2.1.12
Samba 4.17.5
使ったこのdfreeスクリプトWindowsがファイルエクスプローラに正しい使用スペースと残りの空きスペースを報告するようにします。
#!/bin/bash
USED=$((`zfs get -o value -Hp used $1` / 1024)) > /dev/null
AVAIL=$((`zfs get -o value -Hp available $1` / 1024)) > /dev/null
TOTAL=$(($USED+$AVAIL)) > /dev/null
echo -ne $TOTAL $AVAIL
これは期待どおりに機能します。
しかし、これはエンドユーザーに混乱を招いた。彼らは、異なる共有について報告された容量がわずかに異なることを見て、異なるサーバーでなければならないことを意味すると考え、私に電話して理由を尋ねました。
そのため、Windowsで使用されているスペースと容量を報告したいと思います。フルZFSプール使用されたスペースと空きスペースは、共有がマップされた個々のデータセットではなく、共有に関係なく報告されます。
理論的には$ 1をプール名(この場合は「タンク」)に変更する必要がありますが、報告されたディスク容量はWindowsでは変更されません。
#!/bin/bash
USED=$((`zfs get -o value -Hp used tank` / 1024)) > /dev/null
AVAIL=$((`zfs get -o value -Hp available tank` / 1024)) > /dev/null
TOTAL=$(($USED+$AVAIL)) > /dev/null
echo -ne $TOTAL $AVAIL
さまざまな修正によって、Windowsが奇妙な値を報告したり、値がまったく報告されないことがあります。
これを行うためにこれまでに見つけた唯一の方法は、zfs getコマンドが返す必要がある項目にUSEDとAVAILをハードコーディングすることです。
#!/bin/bash
USED=11258621113
AVAIL=28766985099
TOTAL=$(($USED+$AVAIL)) > /dev/null
echo -ne $TOTAL $AVAIL
私は何か愚かなものを見逃しましたか?誰でもこれを動作させましたか?
ありがとうございます!
ベストアンサー1
まず、お客様の問題を再現できないため、解決策を提示できず申し訳ありません。私はFreeBSDシステムの12個のSambaインスタンスに対してこのディレクティブを使用したことがなく、dfree command
あなたが説明する問題も経験したことはありません。smb.conf
Sambaはディスク容量統計を照会する方法を知っているようで、Windowsは合理的なディスク使用率指標を報告します。以下を備えたファイルシステムの場合:
$ zfs list -Hpo used,avail tank/r2d2
2209625051136 1605933772800
Windowsディスプレイ:1.45TBのうち3.32TBが利用可能
確かに言う資格はありませんが、Sambaが一般的な数字を決定できない根本的な問題は、ZFSとSambaのアップストリーム統合の一部の欠陥にある可能性があります。少なくともSambaは、手動で検索したいように、ZFSファイルシステムused
と属性を見つけることができるはずです。avail
私のすべてのシステムはこの問題を自分で解決します。
しかし、より基本的なレベルでは、あなたの投稿は、ZFSがディスクストレージのパラダイム遷移であることをあなたが認識していることを示しています(ユーザーは認識できないかもしれません)。 1つの明確なヒントは、ファイルシステムの「合計」容量を計算する必要があることです。 ZFS自体には(ファイルシステムレベルで)これに関する概念はなく、実際にユーティリティがsize
アクセスできる属性はありませんzfs list
。
ファイルシステムレベルでは、データ自体が広がるため、used
数値も常にぼやけています。available
ZFSファイルシステムは、ユーザーがそれを認識せずにすぐにデータを圧縮するように構成でき、しばしばそうします。したがって、ユーザーは100Gの空き容量を持つボリュームを見て、圧縮可能な10Gファイルを保存し、ボリュームに空き容量が90Gに減らず、まだ95Gの空き容量があるという事実に混乱を招く可能性があります。彼らはサーバーのディスクアレイが10Gのファイルを保存しているように見えますが、「利用可能な」スペースは5GBしか減らないという事実に驚くでしょう。このためです圧縮はユーザーにとって透明です。。
言い換えれば、ユニバーサル4TBドライブを使用することです。その「能力」とは何ですか?電話でディスクスペースについて尋ねる人が「4TB」と言うこともできます。しかし、ZFSでは物理容量、ハードディスク容量、最低限度で数値であり、データが圧縮できない場合にのみ true です。データが圧縮可能な場合、合計は論理的ドライブの容量(ユーザーが「残りのストレージ容量はどれくらいですか?」と尋ねるときに考える容量)は、おそらく4TBより高いでしょう。以前のlz4
圧縮アルゴリズムを使用しても、私のファイルシステムは3倍以上の圧縮を受け、そのうちの1つはほぼ6倍でした。この速度の場合、「4TB」ドライブの容量は12TBから24TBの間になります。圧縮を使用すると、zstd
圧縮率が2桁に達することがあります。
難しい点は、ZFSがファイルの圧縮率を知っているにもかかわらず、保存済みデータが(used
大logicalused
)の場合、データが実際に書き込まれるまで「使用可能」スペースがどれだけ圧縮可能であるかを確認する方法はありません。つまり、total=used+avail
混乱はused
知られていますがavail
、最小限の影響しか及ぼさないからです。将来のデータストレージモデルによっては、total
実際にはそれを超える可能性があります。used+avail
ZFSからファイルシステム、保存される実際のデータの文脈を除いて、「ディスク容量」などはありません。既知の値を持つファイルシステムがavailable
10Gサイズのファイルなどの追加データを保存すると、2:1に圧縮でき、実際のディスク容量は5Gしか消費しません。したがって、圧縮可能な10Gファイルを保存すると、論理容量が5 GB増加する可能性があります。 10Gのデータを保存すると、見かけの「容量」が5GB増加します。これがユーザーが混乱している理由です。彼らは名目上ドライブを理解していない物理4TB容量まで拡張可能論理的ユーザーデータを2:1に圧縮できる場合、実際のユーザーデータ容量は8TBです。圧縮可能なファイルシステム内のスペースの量を追跡することはavailable
常にtotal
動く目標です。
IMOがプールレベルでディスクスペースメトリックレポートに移動したいと言うと、正しい方向に向かっています。圧縮レベルに関係なく、出力は常にzpool
ドライブで使用または使用されていない(-)実際のバイト数を反映しているため、稼働時間監視システムで実行される操作です。実際、プールレベルでは、ZFSファイルシステムにない「サイズ」属性が表示されます。中古および無料は特にRAID-Zパリティを反映しているため、意味がわずかに少なくなりますが、使用/サイズ比は通常正確です。allocated
size
allocated
$ zpool list -po cap,alloc,size
CAP ALLOC SIZE
56 2256319561728 3985729650688
$ bc <<< 'scale=4; 2256319561728/3985729650688'
.5660
ほとんどの人は、ディスクが「56%いっぱいです」または「92%いっぱいです」と理解できます。しかし、「どのくらい多くのデータを保存できますか?」と尋ねると、答えは「状況によって異なります。」です。
目的のソリューションに近づいたら、投稿を更新してください。ここに掲示した内容のうち、あなたの問題を直接解決するものはありませんが、あなたが直面している困難が技術的なアプローチと同じくらいユーザー教育に根ざしているという事実に言及したいと思います。