사실 이런 일은 이미 가능하다.

파일 시스템은 최대 크기를 정의해야 합니다. 그러나 파일 시스템, 즉 파일은부족한, 크기는 임의의 숫자일 수 있으며 기본 파일 시스템의 파일 시스템 파일이 차지하는 공간과 거의 관련이 없습니다.

파일 시스템, 즉 파일(기본 파일 시스템의 실제 크기보다 훨씬 클 수 있음)에 임의의 최대 크기 제한을 설정해도 괜찮다면 이제 스파스 파일과 그 위에 파일 시스템을 생성할 수 있습니다. 그것:

/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에서 오류가 발생하기 시작합니다. 사용하지 않은 용량이 남아 있습니다.

아니요, 자동으로 지원되지 않습니다.

파일 시스템은 고정된 양의 디스크 공간을 처리하기 위해 생성됩니다. 일부 파일 시스템은 증가를 지원하고 일부는 축소를 지원하지만 사용자 개입 없이는 요청 시 지원되지 않습니다. 언급한 질문에 대한 대답은 수동으로 크기를 조정해야 한다는 것입니다.

물론 수동으로 할 수 있는 일을 자동으로 할 수도 있지만 커널 지원이 필요하고 파일 시스템이 가득 차면 파일 시스템이 가득 찼다고 보고하지 않고 파일 시스템을 확장한다. 또한 파일이 삭제될 때 파일 시스템을 자동으로 축소하려고 합니다. 이는 파일 시스템 끝의 공간을 사용할 수 있도록 데이터를 이동해야 할 수 있으므로 시간이 많이 걸리는 작업일 수 있습니다.

이 작업을 위해 특별히 만들어진 파일 시스템은 성장할 때 마지막에 블록을 할당하고 축소할 때 중간에 블록을 해제할 수 있지만 누구도 그러한 파일 시스템을 만들고 싶어하지 않는 것 같습니다. 물론 직접 하셔도 무방합니다.

VirtualBox의 동적 디스크는 다릅니다. 고정된 최대 크기로 생성되므로 즉시 많은 디스크 공간을 사용하지 않습니다. 블록은 데이터가 기록되는 즉시 할당되며 블록이 사용되지 않기 때문에 축소되지 않습니다.

희소 파일 + 루프 장치 + 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 이미지는 데이터를 수용하기 위해 늘리거나 줄일 수 있을 뿐만 아니라 스냅샷과 "차등" 이미지도 지원합니다.

나에게 가장 좋은 옵션은 을 사용하는 것 같습니다 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