zerofree verbose retorna o que?

Question

zerofree -v /dev/sda1 retornou 123642/1860888/3327744 .

A página man não explica quais são esses números: link

Eu encontrei algum código no github: link

E tem essa linha:

if ( verbose ) {
  printf("\r%u/%u/%u\n", modified, free, fs->super->s_blocks_count);
}

Então eu acho que o número do meio era o espaço livre (em kB?), o primeiro pode ser a quantidade que foi escrita com zeros, e o último me perdeu.

O que você acha?

    

Answer 1

Eu tenho a mesma ferramenta instalada no Fedora 19, e notei no arquivo .spec uma URL que leva a esta página intitulada: Mantendo as imagens do sistema de arquivos esparsas . Esta página incluiu alguns exemplos para criar dados de teste, por isso executei os comandos para criar os arquivos correspondentes.

Exemplo

$ dd if=/dev/zero of=fs.image bs=1024 seek=2000000 count=0
$ /sbin/mke2fs fs.image

$ ls -l fs.image 
-rw-rw-r--. 1 saml saml 2048000000 Jan  4 21:42 fs.image

$ du -s fs.image 
32052   fs.image

Quando eu executei o comando zerofree -v , recebi o seguinte:

$ zerofree -v fs.image 
...counting up percentages 0%-100%...
0/491394/500000

Interrogando com filefrag

Quando usei a ferramenta filefrag para interrogar o arquivo fs.image , obtive o seguinte.

$ filefrag -v fs.image 
Filesystem type is: ef53
File size of fs.image is 2048000000 (500000 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     620:   11714560..  11715180:    621:            
   1:    32768..   32769:   11716608..  11716609:      2:   11715181:
   2:    32892..   33382:   11716732..  11717222:    491:   11716610:
   3:    65536..   66026:   11722752..  11723242:    491:   11717223:
...

O s_block_count referenciado em seu código-fonte também coincidiu com o código-fonte da minha versão de zerofree.c .

    if ( verbose ) {
            printf("\r%u/%u/%u\n", nonzero, free,
                            current_fs->super->s_blocks_count) ;
    }

Portanto, sabemos agora que s_blocks_count são os 500.000 blocos de 4096 bytes.

Interrogando com tune2fs

Também podemos consultar o arquivo de imagem fs.image usando tune2fs .

$ sudo tune2fs -l fs.image | grep -i "block"
Block count:              500000
Reserved block count:     25000
Free blocks:              491394
First block:              0
Block size:               4096
Reserved GDT blocks:      122
Blocks per group:         32768
Inode blocks per group:   489
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)

A partir dessa saída, podemos definitivamente ver que os números 2 e 3 relatados por zerofree são de fato:

Free blocks:              491394
Block count:              500000

Voltar para o código-fonte

O 1º número que está sendo informado é, de fato, o número de blocos encontrados que não são zero. Isso pode ser confirmado observando o código-fonte real de zerofree .

Existe um contador chamado nonzero , que está sendo incrementado a cada vez através do loop principal que está analisando os blocos.

            if ( i == current_fs->blocksize ) {
                    continue ;
            }

            ++nonzero ;

            if ( !dryrun ) {
                    ret = io_channel_write_blk(current_fs->io, blk, 1, empty) ;
                    if ( ret ) {
                            fprintf(stderr, "%s: error while writing block\n", argv[0]) ;
                            return 1 ;
                    }
            }

Conclusão

Assim, após algumas análises detalhadas, parece que esses números são os seguintes:

• número de blocos diferentes de zero encontrados
• número de blocos livres dentro do sistema de arquivos
• número total de blocos no sistema de arquivos

Answer 2

Uma pequena correção para a resposta, caso contrário, muito detalhada: o primeiro número é o número de blocos livres diferentes de zero. (Isto é, não conta blocos de arquivos diferentes de zero).

Como tal, nunca é maior que o número de blocos livres.

Se você executar zerofree (sem -n) em um sistema de arquivos, execute-o novamente (opcionalmente com -n para dry-run) você verá que o primeiro número mudou para 0, mesmo com dados de arquivo diferentes de zero o sistema de arquivos.