Início / unix / Perguntas / 780573
Accepted
loco.loop
Asked: 2024-07-22 13:24:06 +0800 CST

O que acontece com os furos de uma lima esparsa quando o espaço é necessário?

  • 772

O cenário

Digamos que você tenha um arquivo esparso de 1 GB em um sistema de arquivos de 2 GB e o arquivo esparso ocupe apenas 0,1 GB de espaço.

As questões)

Acho que você teria 1,9 GB para armazenar dados em disco, certo?

Se houver realmente 1,9 GB de espaço livre no disco, e se eu armazenasse 1,5 GB fora do arquivo esparso, deixando apenas 0,4 GB de espaço livre (1,5 GB fora do arquivo esparso + 0,1 GB do arquivo esparso)? Isso significaria que, mesmo que eu veja o arquivo esparso como 1 GB, só conseguirei armazenar 0,5 GB no total dentro dele (0,1 GB em uso + 0,4 GB disponíveis)?

O que o sistema operacional faria neste caso?

Pensamentos

Se o que foi dito acima for verdade, usar um arquivo esparso parece bom por causa do espaço economizado, mas digamos que estou usando esse arquivo como um ponto de armazenamento (dispositivo de loop) e quero contar com esse espaço, acho que usando o arquivo esparso não seria uma boa ideia porque caso eu precisasse de 1 GB inteiro não conseguiria usá-lo. Talvez seja melhor usar um arquivo não esparso.

filesystems

2 respostas

  1. Best Answer

    Isso significaria que, mesmo que eu veja o arquivo esparso como 1 GB, só conseguirei armazenar 0,5 GB no total dentro dele (0,1 GB em uso + 0,4 GB disponíveis)?

    Sim.

    O que o sistema operacional faria neste caso?

    Se você tentar usar mais do que o espaço livre disponível, será informado que não há mais espaço:

    % dd if=/dev/zero of=100MB.bin bs=1024 count=102400 # 100 MB image to work on
102400+0 records in
102400+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 4.9645 s, 21.1 MB/s
% ls -sh 100MB.bin
101M 100MB.bin
% mkfs -t ext4 -q 100MB.bin
% mkdir 100MB
% sudo mount 100MB.bin 100MB
% sudo chown $USER 100MB -R

% truncate -s 1TB 100MB/foo  # A 1 TB sparse file
% dd if=/dev/zero of=100MB/bar bs=1024 count=51200 # But something else is using 50 MB
51200+0 records in
51200+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 2.01964 s, 26.0 MB/s
% dd if=/dev/zero of=100MB/foo bs=1024 skip=102400 count=102400 conv=notrunc
dd: error writing '100MB/foo': No space left on device
31931+0 records in
31930+0 records out
32696320 bytes (33 MB, 31 MiB) copied, 1.64666 s, 19.9 MB/s
% du -h --apparent-size 100MB/foo; du -h 100MB/foo
932G    100MB/foo
32M 100MB/foo

    Se o que foi dito acima for verdade, usar um arquivo esparso parece bom por causa do espaço economizado, mas digamos que estou usando esse arquivo como um ponto de armazenamento (dispositivo de loop) e quero contar com esse espaço, acho que usando o arquivo esparso não seria uma boa ideia porque caso eu precisasse de 1 GB inteiro não conseguiria usá-lo. Talvez seja melhor usar um arquivo não esparso.

    Isso é algo para o qual você terá que fazer uma avaliação de risco e decidir por si mesmo. É um ato de equilíbrio. Se quiser ter certeza absoluta de que terá espaço, você terá que reservar o espaço com antecedência e não usar um arquivo esparso.

    • 13

  2. Gostei da resposta do @muru. Brincando, encontrei algumas descobertas interessantes que seriam muito longas para serem comentadas. Então aqui estão meus dois centavos.

    Testes com tamanho e mkfs

    mkfs cria um arquivo esparso

    Aparentemente, o mkfs torna o arquivo de 100 MB.bin esparso por padrão

    $ dd if=/dev/zero of=100MB.bin bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 1.54324 s, 67.9 MB/s

$ ls -sh 100MB.bin
100M 100MB.bin

$ mkfs -t ext4 100MB.bin
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks: done
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: cb3c57f4-0119-47da-b39e-4fbbff119a8e
Superblock backups stored on blocks:
    8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

$ ls -sh 100MB.bin
320K 100MB.bin

$ du -h 100MB.bin
320K    100MB.bin

$ du --apparent-size -h 100MB.bin
100M    100MB.bin

$ rm 100MB.bin

    mkfs com nodiscard

    Mas aparentemente usando nodiscard ele não converte o arquivo em um arquivo esparso. Mas ainda reduz o tamanho do 100MB.bin.

    $ mkfs -t ext4 -E nodiscard 100MB.bin
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: dab15e3b-43fa-4242-9611-539ad6838f50
Superblock backups stored on blocks:
    8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

$ du --apparent-size -h 100MB.bin
100M    100MB.bin

$ du -h 100MB.bin # But the disk usage is still less tham 100MB, weird?
96M 100MB.bin

$ rm 100MB.bin

    O exemplo completo com informações extras

    O mesmo exemplo da resposta de @muku, mas verificando os tamanhos ao longo do caminho. Também usamos fallocate para fazer furos e tornar o que fizemos ainda mais esparso.

    $ dd if=/dev/zero of=100MB.bin bs=1024 count=102400
102400+0 records in
102400+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 1.67925 s, 62.4 MB/s

$ ls -sh 100MB.bin
100M 100MB.bin

$ mkfs -t ext4 100MB.bin
mke2fs 1.44.5 (15-Dec-2018)
Discarding device blocks: done
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: f185f88f-20ef-4d28-b203-f3e6272c732b
Superblock backups stored on blocks:
    8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

$ ls -sh 100MB.bin
320K 100MB.bin

$ du --apparent-size -h 100MB.bin
100M    100MB.bin

$ mkdir 100MB.mount

$ sudo mount 100MB.bin 100MB.mount

$ sudo chown -R $USER 100MB.mount

$ du -h 100MB.bin
324K    100MB.bin

$ # Using 1T instead of 1TB
$ # T=power of 1024, TB=power of 1000
$ truncate -s 1T 100MB.mount/1T_sparse

$ ls -sh 100MB.bin
336K 100MB.bin

$ dd if=/dev/zero of=100MB.mount/50M_nosparse bs=1024 count=51200
51200+0 records in
51200+0 records out
52428800 bytes (52 MB, 50 MiB) copied, 0.919962 s, 57.0 MB/s

$ du -h --apparent-size 100MB.mount/1T_sparse; du -h 100MB.mount/1T_sparse; du -h --apparent-size 100MB.mount/50M_nosparse; du -h 100MB.mount/50M_nosparse
1.0T    100MB.mount/1T_sparse
0   100MB.mount/1T_sparse
50M 100MB.mount/50M_nosparse
51M 100MB.mount/50M_nosparse

$ dd if=/dev/zero of=100MB.mount/1T_sparse bs=1024 skip=102400 count=102400 conv=notrunc
dd: error writing '100MB.mount/1T_sparse': No space left on device
35135+0 records in
35134+0 records out
35977216 bytes (36 MB, 34 MiB) copied, 0.550553 s, 65.3 MB/s

$ du -h --apparent-size 100MB.mount/foo; du -h 100MB.mount/foo
932G    100MB.mount/foo
35M 100MB.mount/foo

$ du -h 100MB.bin; du -h --apparent-size 100MB.bin
85M 100MB.bin
100M    100MB.bin

$ # Using fallocate to "punch holes"
$ # where there were a bunch of zeros
$ fallocate -d 100MB.mount/1T_sparse
$ fallocate -d 100MB.mount/50M_nosparse

$ du -h --apparent-size 100MB.mount/1T_sparse; du -h 100MB.mount/1T_sparse; du -h --apparent-size 100MB.mount/50M_nosparse; du -h 100MB.mount/50M_nosparse
1.0T    100MB.mount/1T_sparse
0   100MB.mount/1T_sparse
50M 100MB.mount/50M_nosparse
0   100MB.mount/50M_nosparse

$ du -h 100MB.bin
85M 100MB.bin

$ sudo umount 100MB.mount

$ fallocate -d 100MB.bin

$ du -h 100MB.bin
4.0M    100MB.bin
    • 2

relate perguntas