files/partitions question
A.Fadyushin at it-centre.ru
A.Fadyushin at it-centre.ru
Wed Sep 28 10:36:25 UTC 2005
> -----Original Message-----
> From: redhat-install-list-bounces at redhat.com
[mailto:redhat-install-list-
> bounces at redhat.com] On Behalf Of Rick Stevens
> Sent: Tuesday, September 27, 2005 10:05 PM
> To: Getting started with Red Hat Linux; Mark Knecht
> Subject: Re: files/partitions question
>
> On Tue, 2005-09-27 at 10:01 -0700, Mark Knecht wrote:
> > Hi,
> > Probably a simple question for some wily old-timer. ;-)
> >
> > I have a system in which the root partition seems to be getting a
> > bit full. It got up to about 96% full and I've cleared some things
> > out, but now I want to understand what's still there and using up
8GB.
> >
> > dragonfly / # df
> > Filesystem 1K-blocks Used Available Use% Mounted on
> > /dev/hda8 9621848 8121392 1011680 89% /
> > udev 249524 360 249164 1% /dev
> > /dev/hda2 50394996 47146084 688956 99% /Musiclib
> > /dev/hda3 30233928 1792032 26906084 7% /home
> > /dev/hda9 9621848 2726716 6406356 30% /CODE
> > /dev/hda10 2893628 405328 2341308 15% /var
> > none 249524 0 249524 0% /dev/shm
> > myth14:/video 225373664 110171552 103753792 52% /video
> > dragonfly / #
> >
> > From the du man page it seems that I should be able to run du -x
and
> > only get the usage of the specific drive and not the partitions that
> > are on other drives, so I try it:
> >
> > dragonfly / # du -x /
> > 16 /lost+found
> > 4 /boot
> > 5392 /bin
> > 0 /dev
> > <SNIP>
> > 7964 /root
> > 4 /Froot
> > 12 /Musiclib
> > 8 /service
> > 8 /video
> > 4 /video1
> > 3526456 /
> > dragonfly / #
> >
> > Indeed, this command does not appear to traverse other drives. I
do
> > not see /var, /home, etc., but when it's finished it says that only
> > 3.5 GB are used while the df command tells me 8.1GB is used. Which
is
> > correct?
>
> The most common cause of this is having a process running that's
opened
> a big file for appending, but hasn't actually used any space yet.
"du"
> tells you what's actually being used. "df" will tell you what's
> _reserved_ and MAY be used.
>
> Verify you don't have a process open somewhere that's holding an open
> file. If you've purged a bunch of stuff on the drive, then the free
> space may not show up in "df" until you reboot or close whatever
> application has a file open in that directory.
>
> > As a bonus question, if I know the name of a file and want to
know
> > what drive it's on, how can I do that at the command line? I'd most
> > like a command that reports back file so-and-so resides on
/dev/hda11
> > if possible.
>
> Hooo, boy! The vast majority of programs that do that use either
fixed
> paths (e.g. "whereis") or use the $PATH environment ("which"). If you
> just have a filename, you'd need to use "find" to locate the file,
then
> pass the directory name to a pattern matcher and print the appropriate
> stuff by examining /etc/mtab. There's no simple way to do it. Here's
> a shell script that can do it, but it's bloody nasty!
>
> ------------------------ Cut Here
-------------------------------------
> #!/bin/bash
> RES=`find / -noleaf -name $1 -print`
> if [ $? -ne 0 ]; then
> echo No such file found
> exit 1
> fi
> for LINE in $RES; do
> XLINE=$LINE
> RC=1
> while [ $RC -ne 0 ]; do
> XPATH=`dirname $XLINE`
> XX=`grep $XPATH /etc/mtab`
> RC=$?
> if [ $RC -ne 0 ]; then
> XLINE=$XPATH
> else
> echo -n "$LINE is on "
> echo $XX | awk '{print $1;}'
> break;
> fi
> done
> done
> ------------------------ Cut Here
-------------------------------------
>
> If saved as "/usr/local/bin/whichdrive", then
>
> /usr/local/bin/whichdrive filename
>
> should reveal it. Remember, "find" can take a LONG time. You could
> modify the script to use slocate and a restrictive regular expression
> if you wish. I leave that as an exercise for the reader (meaning "I'm
> too d at mned lazy to write it") :-)
>
> ----------------------------------------------------------------------
> - Rick Stevens, Senior Systems Engineer rstevens at vitalstream.com -
> - VitalStream, Inc. http://www.vitalstream.com -
The difference between results of 'du' and 'df' commands usually is due
to the existence of file(s) which has been open by some process and then
deleted (by the same or other process) while the file is opened. Such a
file will be present on the file system until the all processes which
opened it will close it or exit. However, the file will not be present
in the directories (I assume that you do not have hard links to that
file) and, therefore, will not be accessible by other processes
(including 'du') which did not open it before deletion.
The 'du' command actually scans the directories given in the command
line and sums sizes of files it found in the directories (actual disk
space occupied by file, not the logical file size shown by 'ls' - this
difference is significant for sparse files), and due to this could not
count the size of files which has no name (such as files described
above) nor the size of structures of the filesystem itself (such as
inode tables). The 'df' command uses the information at the filesystem
level and counts all occupied space on the disk without regard to the
contents of that space (i.e. it will count space occupied by deleted but
still opened files and filesystem structures, the size of such
structures is usually insignificant in comparison with the size of
files). Therefore when the deleted but still open files are present, the
sum of file sizes on a filesystem reported by 'du' will be less than the
size of used space on the filesystem reported by 'df'.
If the reason for difference in you case is due to such a deleted file,
you can reboot the system (or unmount and than mount again the
filesystem in question). After that the space occupied by deleted but
still open files will be reclaimed and marked as free - the difference
in reported sizes should disappear.
Alexey Fadyushin.
Brainbench MVP for Linux.
http://www.brainbench.com
More information about the Redhat-install-list
mailing list