次のようなことをしたい
mkfs -t btrfs filedrive
mount filedrive /media/fuse
特定のサイズを指定せずにマウントされたファイルシステムにファイルを書き込むときにファイルサイズを増やし、削除するときにファイルサイズを縮小できるようにしたいと思います。
これを行うメカニズムはありますか？
私も見たことがあるこの問題理論的には手動で管理できることを知っていますが、私の質問はecryptfsとは関係がなく、むしろ自動面に焦点を当てています。私はファイル内のファイルシステムの種類について特に気にしません。
また、同様の操作を実行できる既存のシステム、特にVirtualBoxの動的ディスクも知っています。実際に仮想マシンを実行せずにそれを使用できる方法や同様の方法がある場合、それも満足です。
答え1
実際、これはすでに可能です。
ファイルシステムは最大サイズを定義する必要があります。しかし、ファイルシステム、つまりファイル足りない、サイズは任意の数にすることができ、基本ファイルシステムのファイルシステムファイルが占めるスペースとほとんど関係ありません。
ファイルシステム、つまりファイル（デフォルトのファイルシステムの実際のサイズよりはるかに大きくなる可能性があります）に任意の最大サイズ制限を設定しても構わない場合は、スパースファイルとその上にファイルシステムを作成できます。それ：
/tmp# df -h .
Filesystem Size Used Avail Use% Mounted on
<current filesystem> 20G 16G 3.0G 84% /
/tmp# dd if=/dev/null bs=1 seek=1024000000000 of=testdummy
0+0 records in
0+0 records out
0 bytes copied, 0.000159622 s, 0.0 kB/s
/tmp# ll testdummy
-rw-r--r-- 1 root root 1024000000000 Feb 19 08:24 testdummy
/tmp# ll -h testdummy
-rw-r--r-- 1 root root 954G Feb 19 08:24 testdummy
ここに保存されているファイルシステムよりはるかに大きいように見えるファイルを作成しました。
/tmp# du -k testdummy
0 testdummy
...しかし、これまでは実際にディスク容量をまったく占めていません（inodeや他のメタデータを除く）。
losetupその上にファイルシステムを作成して使用することは完全に可能です。実際、ファイルにデータを書き込む各書き込み操作により、ファイルのスペース要件が増大します。つまり、報告されたファイルサイズはls -l常にランダムな数字のままになりますが、報告されたファイルがディスクに占める物理スペースはdu増えます。
mountオプションを使用してファイルシステムをファイルとしてマウントすると、折りたたみがdiscard自動的に行われます。
/tmp# losetup /dev/loop0 testdummy
/tmp# mkfs.ext4 /dev/loop0
/tmp# mount -o discard /dev/loop0 /mnt
/tmp# du -k testdummy
1063940 testdummy
/tmp# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/loop0 938G 77M 890G 1% /mnt
/tmp# cp /boot/initrd.img /mnt
/tmp# du -k testdummy
1093732 testdummy
/tmp# rm /mnt/initrd.img
/tmp# du -k testdummy
1063944 testdummy
自動縮小には次のものが必要です。
1.）ファイルシステムの種類filesystem-as-fileはdiscardマウントオプションをサポートしています（ファイルシステムドライバがどのブロックを解放できるかをプライマリシステムに通知できるように）。
2.）そして、基本ファイルシステムのファイルシステムタイプは、「ホールパンチング」、つまりオプションを含むシステムコールをサポートしfallocate(2)ますFALLOC_FL_PUNCH_HOLE（したがって、デフォルトのファイルシステムは、以前にファイルシステムに割り当てられたいくつかのブロックを再び希少ブロックとしてファイルとしてマークします。を指示することができます）。
3.）そしてカーネルバージョン3.2以降を使用しているので、ループデバイスのサポートにはこれに必要なインフラストラクチャがあります。
https://outflux.net/blog/archives/2012/02/15/discard-hole-punching-and-trim/
すぐに縮小しても問題ない場合は、マウントオプションをfstrim使用するのではなく、定期的にファイルシステムからファイルとして実行できます。discard基本ファイルシステムの使用量が非常に多い場合は、即時縮小を避けることで、基本ファイルシステムの断片化を最小限に抑えるのに役立ちます。
このアプローチの問題は、基本ファイルシステムがいっぱいになると正しく処理されないことです。デフォルトのファイルシステムにスペースがなくなった場合、ファイルシステム-i-fileにいくつかのスペースがあるように見えますが、希薄な「穴」を実際のデータに置き換えようとすると、ファイルシステム-i-fileでエラーが発生し始めます。未使用容量が残っています。
答え2
いいえ、自動的にはサポートされません。
ファイルシステムは、固定量のディスク容量を処理するために作成されます。一部のファイルシステムは増加をサポートし、一部は縮小をサポートしますが、ユーザーの介入なしには要求に応じてサポートされません。上記の質問に対する答えは、手動でサイズを変更する必要があることです。
もちろん、手動でできることを自動的に行うこともできますが、カーネルサポートが必要であり、ファイルシステムがいっぱいになるとファイルシステムがいっぱいだと報告せずにファイルシステムを拡張する。また、ファイルが削除されたときにファイルシステムを自動的に縮小しようとします。これは、ファイルシステムの終わりにスペースを使用できるようにデータを移動する必要があるため、時間がかかる作業になる可能性があります。
このために特別に作成されたファイルシステムは、成長時に最後にブロックを割り当て、縮小したときに途中でブロックを解放できますが、誰もそのようなファイルシステムを作成したくないようです。もちろん直接しても構いません。
VirtualBoxの動的ディスクは異なります。固定された最大サイズで作成されるため、すぐに多くのディスク容量を使用しません。ブロックはデータが書き込まれるとすぐに割り当てられ、ブロックが使用されないため縮小されません。
答え3
希少ファイル+ループデバイス+ TRIMを許可された方法で使用することをお勧めしますが、問題がXYの問題ではないとはわかりません。単にサブディレクトリ/サブツリーを使用するのはどうですか？必要に応じて拡張および縮小され、mount --bind他の場所でNFSまたはNFSマウントを使用することもできます;-)
また、同様の操作を実行できる既存のシステム、特にVirtualBoxの動的ディスクも知っています。実際に仮想マシンを実行せずにそれを使用できる方法や同様の方法がある場合、それも満足です。
でqemu-ndb次のこともできます。所有者システムでサポートされているすべてのディスクイメージqemu:
# modprobe nbd
# qemu-nbd --discard=unmap -c /dev/nbd1 image.qcow2
# kpartx -a /dev/nbd1
# mount /dev/mapper/nbd1p1 /mount/point
...
# fstrim -v /mount/point
...
# qemu-nbd -d /dev/nbd1
Qemuのqcow2イメージは、データを収容するために増減することができるだけでなく、スナップショットと「差分」イメージもサポートします。
答え4
私にとって最良のオプションは使用しているようですtruncate。自動的に拡張されます。トリミングできるかどうかはよくわかりません。
https://superuser.com/questions/1096549/file-based-dynamically-allocation-hard-disk-on-linux
truncate -s 1G /tmp/file.img
du -h /tmp/file.img
#1.0K /tmp/file.img
du -h --apparent-size /tmp/file.img
#10G /tmp/file.img
losetup -f # or use mount to a mountpoint
#/dev/loop12
losetup /dev/loop12 /tmp/file.img
mkfs.ext4 -m0 /dev/loop12