btrfsメタデータを拡張する方法は？

TL;DR メタデータ (btrfs が一般的な空間不足条件を経験しない場合)自動的に増加する。割り当てられていない空き領域がない場合、自動インクリメントはブロックされます。ただし、btrfs必要以上のスペースがデータセクションに割り当てられている場合は、再割り当てできます。これをbalancebtrfs では -ing といいます。

サポートされているブロックデバイスに割り当てられていないメモリが十分であると仮定すると、ファイルbtrfsシステムのメタデータ部分は、OPが想定したように自動メモリを割り当ててメタデータを増減します。

したがって、答えは次のようになります。はい（メモリー／使用可能なスペースが不足していない場合btrfs）、メタデータは次のように自動的にインクリメントされます。

40GB（1）btrfsの初期割り当て設定（デバイスから）を見てみましょう。

$> btrfs filesystem df /
Data, single: total=25.00GiB, used=24.49GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=1.55GiB, used=1.33GiB
GlobalReserve, single: total=85.41MiB, used=0.00B

(2) ご覧のとおり、メタデータを保存するためにファイルシステムに割り当てられたスペースは 1.55GiB であり、そのうち 1.33GiB なのでほぼすべて使用されます (OP の場合、おそらくこのようなことが発生したでしょう)

(3) 追加するメタデータを追加します。これを行うには、--reflink=alwaysコマンドオプションを使用して/ homeフォルダをコピーしますcp。

$> cp -r --reflink=always /home /home.copy

(4) (/home に多くのファイルがあると仮定) ファイルシステムに多くの新しいデータが追加され、実際に使用するデータは余分な--reflinkスペースを使用しないため、書き込み中にコピーメカニズムを使用します。 。つまり、ほとんどのメタデータがファイルシステムに追加されます。私たちは別の外観を見ることができます

$> btrfs filesystem df /
Data, single: total=25.00GiB, used=24.65GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=2.78GiB, used=2.45GiB
GlobalReserve, single: total=85.41MiB, used=0.00B

ここでメタデータに割り当てられた空間は次btrfsのようなことがわかる。自動的にスケーラビリティを高めます。

これは自動的に行われるため、通常はユーザーが検出しません。しかし、場合によっては、ほとんどの場合、ファイルシステム全体がいっぱいになります。このような場合は、btrfs「トリム」を開始し、メタデータに割り当てられたスペースが自動的に増える可能性があります。たとえば、すべてのスペースがさまざまな部分（Data、System、Metadata、GlobalReserve）に割り当てられているためです。混乱しても、まだ明らかな余地があるかもしれません。たとえば、次のようになります。

$> btrfs filesystem df /
Data, single: total=38.12GiB, used=25.01GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=1.55GiB, used=1.45GiB
GlobalReserve, single: total=85.41MiB, used=0.00B

見てわかるように、システムではすべてが正常ですが、新しいファイルのデータのためのスペースがまだありますが、メタデータ（OPの場合のように）が低いため、割り当ては40GiBやや外れました。ファイルシステムをサポートするデバイスには自動的にメモリを割り当てることはできません（合計クォータを追加すると38.12G+1.55G+..~= 40GiB）。balancebtrfs

ただし、ファイルシステムの一部に割り当てられた余分な空き容量があるため、databtrfsのバランスを取ることが有用または必要です。バランスとは、すでに割り当てられているスペースを再割り当てすることを意味します。

ＯＰの場合、何らかの理由で割り当ての様々なbtrfs部分間で不均衡が生じたと仮定することができる。

残念ながら、原則として空のブロック（データに割り当てられている）を検索して、それをより良いユーザー（ほとんどの使い果たされたメタデータスペース）に渡す必要がある単純なコマンドは、空のブロックがsudo btrfs balance -dusage=0見つからないため失敗する可能性があります。

したがって、開発者は、btrfsスペースを確保するためにデータブロックを再配置する必要がある時点での使用制限を徐々に増やすことをお勧めします。

したがって、結果が次のような場合

$> sudo btrfs balance -dusage=0
Done, had to relocate 0 out of 170 chunks 

再配置なし、何か措置を講じる必要がある

$> sudo btrfs balance -dusage=5
Done, had to relocate 0 out of 170 chunks  <--(again fail)
$> sudo btrfs balance -dusage=10
Done, had to relocate 0 out of 170 chunks  <--(again fail)
$> sudo btrfs balance -dusage=15
Done, had to relocate 2 out of 170 chunks  <--(success)

btrfsもう一つの答えは、ノードサイズの影響を示唆していました。他の回答で述べたように、ノードサイズはファイルmkfs.btrfsシステムの作成時に一度だけ設定されます。理論的には、ノードサイズをより低い値に変更できる場合（可能であれば）、メタデータサイズも小さくできます（ただしそうではありません！）。

ただし、ノードサイズは、どのような方法で割り当てられたメタデータスペースを拡張または増やすのにも役立ちません。代わりに、最初はスペースを節約するのに役立ちます。ただし、ノードのサイズが小さいからといってメタデータのサイズが小さくなるわけではありません。実際、いくつかの状況では、ノードはより多くの「リンク」を含むことができるので、ノードサイズが大きいほど、btrfsのツリー巡回長が短くなることを示すことができる。