是否可以動態增加文件系統作為文件？
我想做一些類似的事情
mkfs -t btrfs filedrive mount filedrive /media/fuse在不指定特定大小的情況下，我希望能夠在將文件寫入已掛載的文件系統時使文件增大，並在刪除文件時縮小文件。
有什麼機制嗎？
我也看過這個問題，我知道它理論上可以手動管理，但我的問題與 ecryptfs 無關，而是集中在自動方面。我並不特別關心文件中的文件系統類型。
我也知道做類似事情的現有系統：特別是 VirtualBox 的動態磁碟。如果有某種方法可以使用這些——或類似的東西——而不實際執行虛擬機，我也會對此感到滿意。
實際上，類似的事情已經成為可能
文件系統需要具有定義的最大大小。但是由於文件系統作為文件可以是sparse，所以該大小可以是任意數字，這與文件系統作為文件在底層文件系統上佔用多少空間沒有太大關係。
如果您可以接受為文件系統即文件設置任意最大大小限制（可能遠大於底層文件系統的實際大小），您現在可以在其上創建一個稀疏文件和一個文件系統：
/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會增加。如果你使用
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掛載選項。如果底層文件系統非常繁忙，避免立即收縮可能有助於最大限度地減少底層文件系統的碎片。這種方法的問題在於，如果底層文件系統變滿了，它就不會被很好地處理。如果底層文件系統中不再有空間，文件系統即文件將在嘗試用實際數據替換稀疏的“漏洞”時開始接收錯誤，即使文件系統即文件似乎還有一些未使用的容量.