Tak! Wygląda na to, że to możliwe. Sprawdźmy, jak można to osiągnąć. Zauważ, że nie tworzy to prawdziwego systemu plików na żądanie, ponieważ gdy osiągnie maksymalny rozmiar pliku rozrzedzonego, zgłosi błędy „brak miejsca”, jeśli nadal trzeba zapisać więcej danych.
Początkowo badałem Thin Provisioning , dobrze znaną technologię pozwalającą zaoszczędzić miejsce na dysku w scenariuszach wirtualizacji. Niestety, w typowych przypadkach użycia Linuksa wydaje się, że jest dostępny tylko z LVM . Ponieważ wydaje się to nieco poza zakresem twojego pytania, szukałem czegoś innego.
Drugą koncepcją, którą zbadałem, jest Sparse File . Jest to dokładnie dostosowane do twojego pytania i ... początkowo wątpiłem: „ OK. Mogę utworzyć rzadki plik. Ale co się stanie, gdy zainicjuję go jako kontener LUKS? Czy taka inicjalizacja przydzieli całą dostępną przestrzeń? Jeśli nie, co się stanie, gdy zainicjuję system plików w takim kontenerze? Czy mkfs.ext4przydzieli całą dostępną przestrzeń? ”. Ponieważ nie miałem odpowiedzi, postanowiłem spróbować. Zobaczmy więc, co się stało.
Zacznijmy od mojego obecnego systemu, w którym mam tylko 3,3 G wolnego miejsca w /repositorysystemie plików:
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,3G 99% /repository
Stwórzmy 10G rzadki plik w takim systemie plików, wraz z:
root@iMac-Chiara:~# dd of=/repository/file_container.img bs=1G count=0 seek=10
0+0 record dentro
0+0 record fuori
0 byte (0 B) copiati, 0,000119606 s, 0,0 kB/s
i sprawdźmy, czy ... to naprawdę rzadki plik:
root@iMac-Chiara:~# ls -lh /repository/file_container.img
-rw-r--r-- 1 root root 10G dic 12 19:48 /repository/file_container.img
OK. Mamy więc plik 10G w systemie plików, który wcześniej miał 3,3G wolnego miejsca. Ile jeszcze wolnego miejsca mam?
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,3G 99% /repository
Nadal 3,3G. Miły. Sparse-file to naprawdę ... sparse-file ;-) Przejdźmy dalej, tworząc kontener LUKS w takim pliku 10G i ... zobaczmy, czy zabraknie miejsca:
root@iMac-Chiara:~# losetup /dev/loop0 /repository/file_container.img
root@iMac-Chiara:~# cryptsetup -y luksFormat /dev/loop0
WARNING!
========
Ciò sovrascriverà i dati in /dev/loop0 in modo irreversibile.
Are you sure? (Type uppercase yes): YES
Inserire la passphrase LUKS:
Verify passphrase:
root@iMac-Chiara:~# cryptsetup luksOpen /dev/loop0 secretfs
Inserire la passphrase per /dev/loop0:
root@iMac-Chiara:~#
Więc teraz mam otwarty secretskontener zdefiniowany na moim rzadkim pliku 10G przechowywanym w systemie plików posiadającym tylko 3,3G wolnego miejsca.
Ile jeszcze wolnego miejsca mam?
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,3G 99% /repository
Wspaniale! Nadal 3,3 GB. Nasz zaszyfrowany pojemnik nie wymagał głównie miejsca!
Sprawdźmy, czy wszystko jest w porządku lub czy jest coś dziwnego w naszej konfiguracji:
root@iMac-Chiara:~# cryptsetup status secretfs
/dev/mapper/secretfs is active.
type: LUKS1
cipher: aes-cbc-essiv:sha256
keysize: 256 bits
device: /dev/loop0
loop: /repository/file_container.img
offset: 4096 sectors
size: 20967424 sectors
mode: read/write
Wszystko wydaje się w porządku, więc zacznijmy używać takiego pojemnika do przechowywania czegoś. Zacznijmy od utworzenia w nim systemu plików EXT4:
root@iMac-Chiara:~# mkfs.ext4 /dev/mapper/secretfs
mke2fs 1.42.5 (29-Jul-2012)
Etichetta del filesystem=
OS type: Linux
Dimensione blocco=4096 (log=2)
Dimensione frammento=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
655360 inodes, 2620928 blocks
131046 blocks (5.00%) reserved for the super user
Primo blocco dati=0
Maximum filesystem blocks=2684354560
80 gruppi di blocchi
32768 blocchi per gruppo, 32768 frammenti per gruppo
8192 inode per gruppo
Backup del superblocco salvati nei blocchi:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Allocating group tables: fatto
Scrittura delle tavole degli inode: fatto
Creating journal (32768 blocks): fatto
Scrittura delle informazioni dei superblocchi e dell'accounting del filesystem: fatto
root@iMac-Chiara:~#
Wygląda na to, że zadziałało, ponieważ nie było śladu „brak miejsca”. Sprawdźmy:
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 258G 3,2G 99% /repository
Uhm ... więc coś się stało. Straciliśmy coś 100M przestrzeni, ale .... jest to oczekiwane zachowanie: stworzenie systemu plików EXT4 DO wymagają pisanie partii metadanych. Więc to normalne, że część przestrzeni została wykorzystana przez proces tworzenia.
Czy to „działający” system plików EXT4?
root@iMac-Chiara:~# tune2fs -l /dev/mapper/secretfs
tune2fs 1.42.5 (29-Jul-2012)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: e63321c3-cee7-478d-a6af-cbdcaf1be1f7
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 655360
Block count: 2620928
Reserved block count: 131046
Free blocks: 2541265
Free inodes: 655349
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 639
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Sat Dec 12 19:58:05 2015
Last mount time: n/a
Last write time: Sat Dec 12 19:58:05 2015
Mount count: 0
Maximum mount count: -1
Last checked: Sat Dec 12 19:58:05 2015
Check interval: 0 (<none>)
Lifetime writes: 131 MB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: c8b3bf1b-9f05-4267-85d3-2ecfdbaa6dc3
Journal backup: inode blocks
Tak! Wygląda dobrze.
Więc teraz mamy system plików EXT4 zapisany w otwartym kontenerze LUKS zdefiniowanym na szczycie rzadkiego pliku 10G przechowywanego w systemie plików 3.3G.
Sprawdźmy, czy wszystko działa poprawnie, przydzielając miejsce „na żądanie”.
Zacznijmy od zapisania 500 mln fałszywych danych w zaszyfrowanym FS
root@iMac-Chiara:~# mkdir /mnt/temp
root@iMac-Chiara:~# mount /dev/mapper/secretfs /mnt/temp
root@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/random_data.bin bs=1M count=512
512+0 record dentro
512+0 record fuori
536870912 byte (537 MB) copiati, 2,35214 s, 228 MB/s
root@iMac-Chiara:~#
Czy udało nam się stworzyć plik?
root@iMac-Chiara:~# ls -lh /mnt/temp/random_data.bin
-rw-r--r-- 1 root root 512M dic 12 20:09 /mnt/temp/random_data.bin
Wygląda tak.
Co się stało z naszym prawdziwym systemem plików?
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 259G 2,5G 100% /repository
Uau! „Straciliśmy” nieco ponad 500 milionów. To dobrze, BTW, ponieważ przestrzeń fizyczna jest naprawdę przydzielana na żądanie!
Przechowajmy kolejny plik 2 GB:
root@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/another_random_data.bin bs=1G count=2
2+0 record dentro
2+0 record fuori
2147483648 byte (2,1 GB) copiati, 25,6539 s, 83,7 MB/s
root@iMac-Chiara:~#
Co się stało?
root@iMac-Chiara:~# ls -arlh /mnt/temp
totale 2,6G
-rw-r--r-- 1 root root 512M dic 12 20:09 random_data.bin
drwx------ 2 root root 16K dic 12 19:58 lost+found
-rw-r--r-- 1 root root 2,0G dic 12 20:13 another_random_data.bin
drwxr-xr-x 8 root root 4,0K mag 29 2015 ..
drwxr-xr-x 3 root root 4,0K dic 12 20:12 .
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 261G 484M 100% /repository
root@iMac-Chiara:~#
Bardzo miłe. Co się stanie, jeśli usuniemy plik?
root@iMac-Chiara:~# rm /mnt/temp/random_data.bin
root@iMac-Chiara:~# sync
root@iMac-Chiara:~# ls -arlh /mnt/temp
totale 2,1G
drwx------ 2 root root 16K dic 12 19:58 lost+found
-rw-r--r-- 1 root root 2,0G dic 12 20:13 another_random_data.bin
drwxr-xr-x 8 root root 4,0K mag 29 2015 ..
drwxr-xr-x 3 root root 4,0K dic 12 20:14 .
root@iMac-Chiara:~# df -h /repository
File system Dim. Usati Dispon. Uso% Montato su
/dev/sda3 275G 261G 484M 100% /repository
root@iMac-Chiara:~#
Zgodnie z oczekiwaniami, w przypadku plików rzadkich zachowanie jest dokładnie takie, jak w przypadku alokacji uproszczonej: po przydzieleniu nie można odzyskać miejsca w pamięci po usunięciu pliku. Ale to ogólnie jest OK. Nie ty
W tym momencie odpowiedź na twoje pytanie powinna być kompletna. Dobrze?
Dodanie:
Zobaczmy, co się stanie, gdy pamięć podkreślająca zapełni się:
root@iMac-Chiara:~# dd if=/dev/zero of=/mnt/temp/a_third_random_data.bin bs=1G count=2
2+0 record dentro
2+0 record fuori
2147483648 byte (2,1 GB) copiati, 26,7142 s, 80,4 MB/s
root@iMac-Chiara:~#
Co? wygląda na to, że się udało! Jak to było możliwe? Sprawdźmy!
root@iMac-Chiara:~# ls -arlh /mnt/temp
totale 4,1G
drwx------ 2 root root 16K dic 12 19:58 lost+found
-rw-r--r-- 1 root root 2,0G dic 12 20:17 a_third_random_data.bin
-rw-r--r-- 1 root root 2,0G dic 12 20:13 another_random_data.bin
drwxr-xr-x 8 root root 4,0K mag 29 2015 ..
drwxr-xr-x 3 root root 4,0K dic 12 20:17 .
root@iMac-Chiara:~#
Uhm ... Wygląda dobrze. Jesteśmy pewni?
root@iMac-Chiara:~# df /repository
File system 1K-blocchi Usati Disponib. Uso% Montato su
/dev/sda3 288110208 275070448 0 100% /repository
zabrakło nam miejsca! Bez żadnego błędu!
Nawet jeśli byłoby miło zbadać, co się naprawdę wydarzyło ... Pozostawię to twojej ciekawości i / lub umiejętności rozwiązywania problemów innych członków ServerFault ;-)
Baw się dobrze!
BTW: Testowałem wszystkie powyższe, tutaj:
root@iMac-Chiara:~# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.04
DISTRIB_CODENAME=raring
DISTRIB_DESCRIPTION="Ubuntu 13.04"
root@iMac-Chiara:~# uname -r
3.8.0-31-generic
root@iMac-Chiara:~# dpkg -l cryptsetup-bin
[...]
ii cryptsetup-bin 2:1.4.3-4ubuntu2 amd64 disk encryption support - command line tools
root@iMac-Chiara:~#