/ filling up, how to "pare" mount point?

[Joe Robinson_2]

I have a mount point that has consistently gotten larger and larger, to the point that my / file system is now getting full. Is there a way to correct this situation aside from adding disk?

[Pupil_1]

Looks like you need to have a separte Filesystem for your growing demand !!

If there space in any where in the Machine, then the first step that I can think of is to link the directory to a filesystem that has some spare space !!

[Mel Burslan]

if what you are referring to as "mountpoint", is nothing more than a directory under / filesystem, unfortunately, there is not much you can do, other than creting a new filesystem and mount it under this mountpoint and move the data into that new filesystem.

if you can provide more detail, I am sure you can get more meaningful answers

[IT_2007]

If it is a seperate file system and it might have been mount on / instead of seperate mount point and that is the reason your / being filled up. Create a new mount point like /test, unmount existing logical volume and then mount that file system.

[Rick Garland]

If the mount point in question is a separate filesystem from /, then the / filesystem would not fill up.

You mount point is probably in the same filesystem as /

To see the biggest files in order,
# cd /
# du -x -ka . | sort -nr | more

Starting in the root, the du -x command will list files without crossing filesystems (the -x option). The -ka will list in 1024 blocks (the -k option) and list files (the -a option)

Is it the /dev/ directory? Somebody trying a backup? Not getting to the correct and so the /dev directory usually takes the punishment.

[spex]

Joe,

If haven't already, you should investigate what is causing the root filesystem to fill up. Then takes steps to correct the core problem, instead of just mitigating symptoms.

On one my stock 11.11 systems, the following directories, among a few others, are located on the root filesystem:

/
/etc
/sbin
/dev

Concentrate your search here. This command:

du -xk / | sort -n

will give a list of directories on the root filesystem, sorted by size.

PCS

[Joe Robinson_2]

sorry for the confusion on this. The filesystem (/web) is seperate from root. When doing a long list of /, the /web DIRECTORY shows a size of 4251648. Is that amount of disk taken from /, or is it not included? my root file system is currently 92% full, and I'd rather not have to take the system down (booting from an Ignite tape) to increase the / file system.

[A. Clay Stephenson]

First do a bdf, if your /Web directory shows up as a separate filesystem then the growth of /Web has nothing to do with /. You need to look elsewhere for why / is filling up. Generally the first place to look in / is the /dev/directory. Do a "du -k /dev" -- if you see anything over about 100 (and that is very generous) something is wrong. If there are any regular files under /dev, remove them. Next du / and look for large directories to narrow your search. By the way, it would only take a few core files to fill / up.

[Mel Burslan · Accepted solution]

my rule of thumb when "/" fills up is to run this find command below:

find / -xdev -size +1000000c | xargs ll > /tmp/largefiles.out

there are very few files under the "/" filesystem, which are larger than the 1 MB (roughly) size specified in this find command and you can tell from their location if these are legitimately large files or not.

Some of my wisegys, especially junior sysadmins, think that they can use / as their temporary storage. what can be easier to specify an output file and placing it in /, right ?


As Clay indicated, most likely culprit for an over-inflated / is either core files

( find / -xdev -name core )

or

someone fat-fingering a device file name and sending output of a backup into something like /dev/rmt/* or instead of sending output to /dev/null they may misspell null, creating a file of that name.

[Pupil_1]

bdf o/p and the layout of the FS is required to give a proper reasoning to fix!!

[Bill Hassell]

The size of the directory file /web (it's really a file) is extremely large for two reasons:

1. There were thousands and thousands of files and directories which were then removed. The3 directory is not resized but simply has the entries marked as reuseable. There is no way to return the unused entries except to backup /web, remove the difrectory, recreate and restore /web.

2. The directory really contains thousands of files and the directory size is normal.

Now it is VERY important to type this command:

bdf /web

If the mountpoint at the end of the line shows: /web, then /web is a separate disk and has no effect whatsoever on the / directory. When you analyze /, you can't use ls as it shows mountpoints (which occupy no space on /) as well as real directories like /etc /dev and /sbin which do indeed occupy space in /.

So to analyze / to see why it is growing (I am assuming that:

bdf /

shows the 92% full situation for /. USe the du command to analyze the directories. Trying to find large files will totally miss a bogus directory full of hundreds of small junk files. Post the resulot of this command:

du -kx / | sort -nr | head -20

You will see /sbin and /etc are the largest directories, perhaps 30 to 40 megs each. If anything else shows up at the top of the list, that's your problem directory that needs to be moved.

[Joe Robinson_2]

very good input from everyone! Problem turned out to be data on a NFS share (exported); I confess to overlooking that file system when researching this. Again, great info from everyone, much obliged!

[Joe Robinson_2]

thanks!