Thanks everyone... There where a number of suggestion that worked very well. It
turned out to be a
hidden file from a background task that I didn't know the customer had running.
Ferguson, Neale wrote:
du -x -h --max-depth=1 /
It will then show you the space used by 1st level of directories. Then
find /path -xdev -type f -ls | sort -n -r +6 | more -c
John R. Campbell, Speaker to Machines (GNUrd) {813-356|697}-5322
Adsumo ergo raptus sum
MacOS X: Because making Unix user-friendly was easier than debugging
Windows.
Red Hat Certified Engineer
It can be a real bear when someone deletes the file but leaves the
process that has it open running...
See: http://www.systemtoolbox.com/article.php?articles_id=15
John R. Campbell, Speaker to Machines (GNUrd) {813-356|697}-5322
Adsumo ergo raptus sum
MacOS
PROTECTED] Behalf Of
John Campbell
Sent: Wednesday, December 29, 2004 1:42 PM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] Fw: [LINUX-390] File system full
It can be a real bear when someone deletes the file but
leaves the
process that has it open running...
See: http
What is the fastest way to find out what is filling up disk space? I've been
searching directories
manually and can see nothing that big. It was 70% now it is 100%.
TIA
Dave
--
For LINUX-390 subscribe / signoff / archive access
On Dec 28, 2004, at 5:02 PM, David Heilman wrote:
What is the fastest way to find out what is filling up disk space?
I've been searching directories
manually and can see nothing that big. It was 70% now it is 100%.
Probably /var/log.
inline: graycol.gifinline: pic08638.gifinline: ecblank.gif
The find command can be a big help. I also like du -sk * . It lists
all files and directories and their size (including subdirectories.) It
*really* helps to know what your systems are like normally.
Logs are usually the problem unless something is in a loop. Try top to
see what's
du -x -h --max-depth=1 /
It will then show you the space used by 1st level of directories. Then drill
down using the same command with a different argument. Take a look in /var/log.
I find /var/log/sa fills things up quite quickly (which is why I usually put it
on a device of its own).
