TL; DRメタデータ(btrfsが一般的な低スペース状態に陥っていない場合)は自動的に増加します。未割り当ての空き領域が存在しない場合、自動増加は保留されます。ただし、のデータ部分にbtrfs
必要以上のスペースが割り当てられている場合は、これを再配布することが可能です。これはbalance
btrfsでは-ing と呼ばれます。
のバッキングブロックデバイスに十分な未割り当てメモリがあると仮定するとbtrfs
、ファイルシステムのメタデータ部分は、OPで想定されているように、自動的にメモリを割り当てて、メタデータを増加/拡張します。
したがって、答えは次のとおりです。はい(にメモリ不足/空き容量がない場合btrfs
)、メタデータは次のように自動的に増加します。
(1)btrfs(40GB
デバイス上)の初期割り当て設定を確認しました
$> 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
は、cp
コマンドのオプションを使用して/ homeフォルダーをコピーします。
$> cp -r --reflink=awlways /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
「スタッター」を開始し、メタデータに割り当てられたスペースを自動的に増やすことができない場合があります。その理由は、たとえば、すべてのスペースがすでにパーツ(データ、システム、メタデータ、グローバルリザーブ)に割り当てられているためです。紛らわしいことに、まだ明らかなスペースがあるのは事実です。例は次の出力です。
$> 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
ご覧のとおり、新しいファイルのデータ用のスペースがまだある40GiB
のにbalance
、メタデータ(OPの場合のように)が低いため、システムはすべてですが、割り当ては多少ずれています。btrfs
ファイルシステムをサポートするデバイスへのメモリの自動割り当ては、もはや不可能です(単に、割り当ての合計、38.12G + 1.55G + ..〜= 40GiBを合計してください)。
ただしdata
、ファイルシステムの一部に割り当てられた余分な空き領域があるため、btrfsのバランスを取るために必要な場合があります。バランスは、すでに割り当てられているスペースを再配分することを意味します。
OPの場合、何らかの理由で、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)
もう1つの答えは、btrfs
ノードサイズの影響をほのめかしています。これは、メタデータの増加速度に多少影響します。nodesizeは(他の回答で述べたように)mkfs.btrfs
ファイルシステムの作成時に一度だけ設定されます。理論的には、nodesizeの値を小さくすることが可能であれば、メタデータのサイズを小さくすることができます(可能な場合は不可能です)。ただし、nodesizeは、割り当てられたメタデータスペースの拡大または増加を支援することはできません。代わりに、そもそもスペースの節約に役立っただけかもしれません。ノードサイズを小さくしても、メタデータのサイズが小さくなるとは限りません。実際、ノートに「リンク」が含まれる可能性があるため、ノードサイズが大きくなるとbtrfsのツリートラバースの長さが短くなる場合があります。