Windowsは、ZFSを使用するSambaサーバーで正しく使用されているディスク容量と利用可能なディスク容量を報告しません。

Windowsは、ZFSを使用するSambaサーバーで正しく使用されているディスク容量と利用可能なディスク容量を報告しません。

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.confSambaはディスク容量統計を照会する方法を知っているようで、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数値も常にぼやけています。availableZFSファイルシステムは、ユーザーがそれを認識せずにすぐにデータを圧縮するように構成でき、しばしばそうします。したがって、ユーザーは100Gの空き容量を持つボリュームを見て、圧縮可能な10Gファイルを保存し、ボリュームに空き容量が90Gに減らず、まだ95Gの空き容量があるという事実に混乱を招く可能性があります。彼らはサーバーのディスクアレイが10Gのファイルを保存しているように見えますが、「利用可能な」スペースは5GBしか減らないという事実に驚くでしょう。このためです圧縮はユーザーにとって透明です。

言い換えれば、ユニバーサル4TBドライブを使用することです。その「能力」とは何ですか?電話でディスクスペースについて尋ねる人が「4TB」と言うこともできます。しかし、ZFSでは物理容量、ハードディスク容量、最低限度で数値であり、データが圧縮できない場合にのみ true です。データが圧縮可能な場合、合計は論理的ドライブの容量(ユーザーが「残りのストレージ容量はどれくらいですか?」と尋ねるときに考える容量)は、おそらく4TBより高いでしょう。以前のlz4 圧縮アルゴリズムを使用しても、私のファイルシステムは3倍以上の圧縮を受け、そのうちの1つはほぼ6倍でした。この速度の場合、「4TB」ドライブの容量は12TBから24TBの間になります。圧縮を使用すると、zstd圧縮率が2桁に達することがあります。

難しい点は、ZFSがファイルの圧縮率を知っているにもかかわらず、保存済みデータが(usedlogicalused)の場合、データが実際に書き込まれるまで「使用可能」スペースがどれだけ圧縮可能であるかを確認する方法はありません。つまり、total=used+avail混乱はused知られていますがavail、最小限の影響しか及ぼさないからです。将来のデータストレージモデルによっては、total実際にはそれを超える可能性があります。used+avail

ZFSからファイルシステム、保存される実際のデータの文脈を除いて、「ディスク容量」などはありません。既知の値を持つファイルシステムがavailable10Gサイズのファイルなどの追加データを保存すると、2:1に圧縮でき、実際のディスク容量は5Gしか消費しません。したがって、圧縮可能な10Gファイルを保存すると、論理容量が5 GB増加する可能性があります。 10Gのデータを保存すると、見かけの「容量」が5GB増加します。これがユーザーが混乱している理由です。彼らは名目上ドライブを理解していない物理4TB容量まで拡張可能論理的ユーザーデータを2:1に圧縮できる場合、実際のユーザーデータ容量は8TBです。圧縮可能なファイルシステム内のスペースの量を追跡することはavailable常にtotal動く目標です。

IMOがプールレベルでディスクスペースメトリックレポートに移動したいと言うと、正しい方向に向かっています。圧縮レベルに関係なく、出力は常にzpoolドライブで使用または使用されていない(-)実際のバイト数を反映しているため、稼働時間監視システムで実行される操作です。実際、プールレベルでは、ZFSファイルシステムにない「サイズ」属性が表示されます。中古および無料は特にRAID-Zパリティを反映しているため、意味がわずかに少なくなりますが、使用/サイズ比は通常正確です。allocatedsizeallocated

$ zpool list -po cap,alloc,size
  CAP          ALLOC           SIZE
   56  2256319561728  3985729650688
$ bc <<< 'scale=4; 2256319561728/3985729650688'
.5660

ほとんどの人は、ディスクが「56%いっぱいです」または「92%いっぱいです」と理解できます。しかし、「どのくらい多くのデータを保存できますか?」と尋ねると、答えは「状況によって異なります。」です。

目的のソリューションに近づいたら、投稿を更新してください。ここに掲示した内容のうち、あなたの問題を直接解決するものはありませんが、あなたが直面している困難が技術的なアプローチと同じくらいユーザー教育に根ざしているという事実に言及したいと思います。

おすすめ記事