[Breezy] Incorrect Report by df -h

[Vram]

On Sun, 2006-01-01 at 10:47 +1300, Tim Frost wrote:
> On Sat, 2005-12-31 at 13:10 -0800, Ed Fletcher wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Hi All:
> > 
> > Happy New Year to everyone!
> > 
> > I'm cleaning up a couple of partitions and I'm not getting the results
> > that I expected.  I enabled a root terminal with 'sudo -i' because one
> > of the partitions wouldn't let me delete some of the directories.  I got
> > rid of absolutely everything except for lost+found, which is empty.
> > 
> > This is what I end up with:
> > 
> > root:/mnt # df -h  (other partitions not shown)
> > Filesystem            Size  Used Avail Use% Mounted on
> > /dev/sdb7             9.2G   33M  8.7G   1% /temp
> > /dev/sda2              55G   33M   52G   1% /mnt
> > root:/mnt #
> > 
> > The numbers don't add up.
> 
> This is normal.  Some space is reserved, so that ordinary users can't
> fill a partition to 100% capacity.  The "Avail" column shows the space
> available for non-root users.  If the partition is filled to the point
> where the reserved space is being used, you will see Avail = 0.
> 
> > I know that they are empty.  In sda2 I get:
> > 
> > root:/mnt# ls -al
> > total 24
> > drwxr-xr-x   3 root    root   4096 Dec 31 12:48 .
> > drwxr-xr-x  23 root    root   4096 Nov 29 19:26 ..
> > drwx------   2 (owner) users 16384 Apr 23  2005 lost+found
> > root:/mnt # cd lost+found/
> > root:/mnt/lost+found # ls -al
> > total 20
> > drwx------  2 (owner) users 16384 Apr 23  2005 .
> > drwxr-xr-x  3 root    root   4096 Dec 31 12:48 ..
> > root:/mnt/lost+found #
> 
> Because the lost+found directory is used by fsck, it is normal for it to
> be created with room for a number of entries.  This ensures that fsck
> has space available in the filesystem to record inodes that don't have a
> directory entry.
> 
> 
> > 
> > 'ls -al' shows that there are no files in this partition.  Doing the
> > same check on sdb7 gives me the same result.  But 'df -h' shows almost
> > the exact same result for sdb7 except that the blocks used by lost+found
> > are 49152.
> > 
> > The sdb7 partition is ext3 and sda2 is ext2.  I don't see where the
> > space is being used except that there are high block counts in
> > lost+found in both partitions.  I can likely solve this by unmounting
> > both and rewriting the filesystems, but that wouldn't solve the mystery
> > for me.
> > 
> > Can anybody give me a hint as to what is happening here?
> 
> Reserved space plus room for recovery of lost inodes.
> > 
> > Many thanks,
> > Ed
> > - --
> > Ed Fletcher
> > ed at fletcher.ca
> > 
> 
> 
> Tim
> 


For example


NAME
       mke2fs - create an ext2/ext3 filesystem

SYNOPSIS
       mke2fs [ -c | -l filename ] [ -b block-size ] [ -f
fragment-size ] [ -g blocks-per-group ] [ -i bytes-per-inode ] [ -j ]
[ -J journal-options ] [  -N  number-of-inodes ] [ -n ] [ -m
reserved-blocks-percentage ] [ -o  creator-os ] [ -O feature[,...]  ]
[ -q ] [ -r fs-revision-level ] [ -R raid-options  ]  [  -v  ] [ -F ]
[ -L volume-label ] [ -M last-mounted-   directory ] [ -S ] [ -T
filesystem-type ] [ -V ] device [  blocks-count   ]



  -m reserved-blocks-percentage
              Specify the percentage of the filesystem blocks reserved
for the  super-user.  This value defaults to 5%.



All filesystems <I think..Haven't checked> have a similar option


HTH


Vram





>