7

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

The man page does not explain what those numbers are: http://manpages.ubuntu.com/manpages/natty/man8/zerofree.8.html

I found some code on github: https://github.com/haggaie/zerofree/blob/master/zerofree.c

And there's this line:

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

So I guess the middle number was the free space (in kB?), the first one might be the amount that was written over with zeros, and the last one lost me.

What do you think?

13

I have the same tool installed on Fedora 19, and I noticed in the .spec file a URL which lead to this page titled: Keeping filesystem images sparse. This page included some examples for creating test data so I ran the commands to create the corresponding files.

Example

$ 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

When I ran the zerofree -v command I got the following:

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

Interrogating with filefrag

When I used the tool filefrag to interrogate the fs.image file I got the following.

$ 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:
...

The s_block_count referenced in your source code also coincided with the source code for my version of zerofree.c.

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

So we now know that s_blocks_count is the 500,000 blocks of 4096 bytes.

Interrogating with tune2fs

We can also query the image file fs.image using 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)

From this output we can definitely see that the 2nd and 3rd numbers being reported by zerofree are in fact:

Free blocks:              491394
Block count:              500000

Back to the source code

The 1st number being reported is in fact the number of blocks that are found that are not zero. This can be confirmed by looking at the actual source code for zerofree.

There is a counter called, nonzero which is getting incremented each time through the main loop that's analyzing the blocks.

            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 ;
                    }
            }

Conclusion

So after some detailed analysis it would look like those numbers are as follows:

  • number of nonzero blocks encountered
  • number of free blocks within the filesystem
  • total number of blocks within the filesystem
|improve this answer|||||
  • 1
    That was a really wonderful post. Thank you! (I don't yet have enough reputation to upvote!) – plamtrue Jan 5 '14 at 4:57
1

A small correction to the otherwise very detailed answer: The first number is the number of free non-zero blocks. (I.e. it does not count non-zero file blocks).

As such, it is never larger than the number of free blocks.

If you run zerofree (without -n) on a filesystem, then run it again (optionally with -n for dry-run) you will see that the first number has changed to 0, even with non-zero file data on the filesystem.

|improve this answer|||||
  • 1
    This is not a full answer to the question, but rather a commentary on the accepted answer. Hence it should have gone as a comment to this answer, not as a separate answer. Welcome to the StackExchange Unix discussions. – MelBurslan May 5 '16 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.