My thanks to all who responded . Almost everybody says that there is no
problem in filesystem but discripancy between du and df is due to Oracle
database ( open files / logs being written ) . du and df should be seen in
entirely different prospect .
Thanks specially to :-
I expect that there are open files using space that don't show to the
du command. It's likely the Oracle database.
Ravi Channavajhala [ravi.channavajhala@csfb.com]
You probably are confused by the beahaviour of 'du' and 'df'.
When you issue a 'du' it does something like find, traverses
the entire directory structure, where as df issues a statvfs(2)
call to get the data.
I'm not ruling out file system corruption, but you already did
a fsck to fix this. The only other thing to check is, see if
your directory mountpoint itself has data.
If this is a RAID-5 set ( I wonder the wisdom of creating such
thing with SDS anyway, you should use hardware RAID ), I'm
not sure if the parity disk is being reported by 'df'.
Truss both 'du' and 'df' and see how they are "actually" getting
data.
-ravi
Roy Butler [butlerr@psi.com]
Hello,
I believe that the discrepancy is due to Oracle "pre-allocating" empty
filespace. Some utilities may see this as taken, while others may not. If
you are only seeing this on drives holding database files, this is probably
the right direction to head in. If it is causing problems, like setting
off diskspace warnings, you might run it by Oracle to see if there is some
tunable parameter to change this.
Jeff Lightner [Jeff.Lightner@alltel.com]
I haven't worked much on Sun but this sounds similar to an issue I've
seen on my HP servers. What I've seen there is that if someone
removed a file that was still "open" by a process (usually a log file)
it would only remove the name so one could not see it but the space
would still be in use because of the process that had the file "open".
Initially, like you, we solved this by doing a umount and fsck. Once
we realized what the issue was we started finding the processes that
were using the filesystem and removing them. We used fuser but it
doesn't find everything (at least in HP-UX) so finally downloaded lsof
found it is a great tool for locating such open files.
You simply do "lsof filesystem" and it will show you any processes
that are attached to the filesystem you specified. Moreover it will
show you a column for "size" and usually you will see a large sized
item in the list that has only the filesystem and no file name which
usually turns out to be the process that busies it out. I know lsof
is available for Sun but not sure which sites to get it at - it is
free to download.
Matthew Stier [Matthew.Stier@fnc.fujitsu.com]There can be a discrepancy
between 'df' and 'du'.
There is a technique for opening self-removing temporary files. It involves
opening the file, and then unlinking it. The file stays open as long as the
application doesn't close it, and should the application terminate
abnormally,
the operating system will recover the disk space automatically.
Since the file does consume space, 'df' will register it. Since it does not
have a directory entry, du will not.
Christophe DIARRA [diarra@ipno.in2p3.fr]
Hi !
Are you usings quotas ? In this case try quotacheck on /data1.
Christophe.
Original Problem:-
"Shalabh Sharma (OCS-AHD-AVS)" wrote:
>
> Following are the details of problem faced by me :-
>
> Machine : - Enterprise 250
>
> O.S. :- Solaris 2.6
>
> Other Softwares :- (SUNWmd)Solstice disk suite ( SDS 4.1 ) for RAID5 on
> various filesystems , Oracle for a billing software .
>
> Other details :- We have total 5 filesystems named as /data1 , /data2 ,
> /data3 , /data4 & /data5 in RAID5 . Other than this , we have / , /usr
etc.
> for O.S. .
>
> Problem Description :- /data1 filessystem gives a peculiar problem . If we
> see # df -k , used space is shown as 3.5 GB ( in /data1 )and in % say 85%
.
> At the same time # du -ks /data1 gives used space as 2.6 GB only . Hence
> there is discrepancy is du -ks and df -k . If I umount /data1 , do fsck on
> /data1 device ( /dev/md/rdsk/d11 ) , problem is solved ( no discrepancy
).
S
U BEFORE POSTING please READ the FAQ located at
N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq
. and the list POLICY statement located at
M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy
A To submit questions/summaries to this list send your email message to:
N sun-managers@sunmanagers.ececs.uc.edu
A To unsubscribe from this list please send an email message to:
G majordomo@sunmanagers.ececs.uc.edu
E and in the BODY type:
R unsubscribe sun-managers
S Or
. unsubscribe sun-managers original@subscription.address
L To view an archive of this list please visit:
I http://www.latech.edu/sunman.html
S
T
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:19 CDT