Conference turris::digital_unix

    sometime customers will alias either, or both commands to use -k, which
    show kb instead of 512b blocks. be sure you are looking at teh same
    size units in each case.
    

	Du counts file sizes according to what files have names.  I
	don't know if it keeps track of hard links.  If not it may
	count some files twice or more times.  It can't count files
	which don't have names.  Last, and perhaps most importantly,
	it counts file bytes sizes.

	Df reports the kernel mount table data for space usage.  This
	counts all blocks allocated to files, which can be quite different
	from how many bytes the files has.

	The detailed differences:

	o  Files can have zero to many names.  A file has zero names
	   when the name is unlink(2)ed while still open.  This is
	   often done for temporary files because the file is deleted
	   by the kernel when closed.

	o  Files can have holes of unallocated data that read as NULs.
	   Du will count the same, but df won't.

    Alan,
    
    with respect to sparse files, I'm not sure what you mean by 'du will
    count the same'.  If you mean that du counts sparse (virtual) blocks
    as being real ones, then I must disagree...
    
    I run 'mkbigfile' (source at the end) to produce a sparse file with
    an ostensible size of 100MB:
    
    % mkbigfile
    % ls -l /tmp
    -rw-r--r--   1 urban    system   104857619 Jan 31 02:41 foo.bar
    % du -k /tmp/foo.bar
    16      /tmp/foo.bar
    
    So du understands sparse files, and should not report any more
    blocks in use by this file than df takes into account.
    
    ---- mkbigfile.c ----
    #include <stdio.h>
    
    main()
    {
            FILE *fp;
    
            fp = fopen("/tmp/foo.bar","w");
    
            fprintf(fp,"line one\n");
            fseek(fp,(long) 100*1024*1024,SEEK_CUR);
            fprintf(fp,"last line\n");
            fclose(fp);
    }
    

	FWIW, du most definitly keeps track of hard linked files and will
	*try* to count a multiply hard liked file only once (unless you
	tell it otherwise, see the FLAGS and NOTES extract enclosed below).

	And du also most definitly uses (st_blocks * st_blksize) instead
	of st_size, so holes in sparse files will not be counted.

	Another thing that can account for differences between what
	du and df report is that I don't believe (but am not 100% sure,
	but the fact that du on a zero length file report zero would
	seem to confirm) that st_blocks is only user data blocks allocated
	to the file, and does not include filesystem overheard, such as
	the inode and indirect blocks.

	And the filesystem type may explain why du or df shows a higher
	count on different systems (that .0 mentions).

FLAGS
  -l  Allocates	blocks,	in files with multiple links, evenly among the links.
      By default, a file with two or more links	is counted only	once.

NOTES
  If too many files are	distinctly linked, du counts the excess	files more
  than once.

What file system is being used?  It is possible with advfs for
this output to not be synchronized if quotacheck is not run on reboots
to fix the quota data (which is used by df on advfs).

This is in the advfs release notes, and the current version of sys_check
suggests you run this (and checks for proper settings of fstab entries
so the quotacheck does the right thing)...quotacheck should only be
run when the file system is not very active...

see

http://www-unix.zk3.dec.com/tuning/tools/sys_check/sys_check.html