From: Mark Schubert (Mark.Schubert@cogita.com.au)
Date: Thu Aug 07 2003 - 03:11:06 EDT
Thanks to all those that replied.
Had various replies ranging from:
- use quotacheck to "fix" the discrepancy
- open files are not cleaned up by verify
- use the vdf or vdu command
What I found:
- quotacheck does not work on clusters. I get the error "quotas are not
supported in a cluster environment"
- The verify I ran was an offline verify so there were no open files and the
verify did not resolve the problem.
- The "vdf domain#fileset" command reports exactly the same usage
information as df, which is wrong.
- The "vdf domain" reports correct domain usage, but is not fileset
specific.
- There is no vdu command.
So I still do not have a solution. Any other ideas?
Thanks,
Mark.
> -----Original Message-----
> From: Mark Schubert
> Sent: Wednesday, 6 August 2003 5:20 PM
> To: 'tru64-unix-managers@ornl.gov'
> Subject: Significant disk space usage discrepancy between df and du
>
> We have a V5.1 cluster which is showing significant discrepancies in
> available disk space in one domain.
>
> The following output from df -k shows /app as consuming 6.9GB. It also
> shows the free space of the 2 filesets as being different, when usually
> all filesets in a domain show the same free space. A du -k on /app shows
> it is only consuming 3.4GB of disk space, a difference of 3.5GB from what
> df -k is reporting. A du -k on /home shows 1.5GB consumed which is
> correctly reported by df.
>
> Filesystem 1024-blocks Used Available Capacity Mounted on
> dom0#fset0 8838720 1599308 3703728 31% /home
> dom0#fset1 8838720 6909931 1928789 79% /app
>
> /etc/fstab contains the following for the file systems.
> dom0#fset0 /home advfs rw 0 2
> dom0#fset1 /app advfs rw 0 2
>
> We recently did a verify -d on this domain to cleanup any unlinked files,
> but that made no difference. Verify actually reported there were no
> unlinked files.
>
> I remember hearing something about quotas (or quotacheck) affecting the df
> output, although we are not running quotas.
>
> Any ideas?
>
> Thanks,
>
> Mark
>
>
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:30 EDT