directory / full

[Jimmy_13]

Whit the bdf command the lvol3 (directory /) has 143 MB and 125MB used (88%).
But the command: du -k -x / ,
said that are used 32 MB only of the /.
The lvol3 has a mirror.

What reduce the free space of /?
I need to reduce the use of /, but i don't know which files delete.

I will use the make_recovery how the last opcion.

the attach has the command bdf and du -k -x /


thanks

[hpuxhelp]

go to /var and tried to trim down the log file and remove core file..your /var is at 85%

[Jimmy_13]

thanks, but the problem is in / (lvol3)

[Bill Hassell]

The du vs. bdf question is a fairly common question here in the ITRC forums and the answer is easy: sparse files. A sparse file is one that has been created with 'holes' or unwritten parts. Consider writing a file with record #1, then by seeking to record one million, writing another record and then closing the file. The file has but two records and occupies only a couple of blocks but the missing parts are not stored nor counted in bdf(1) or du(1). Depending on the size of the file and the spareseness, the difference in apparent versus actual size may be VERY large.

Create your own sparse file with:

dd if=/etc/issue of=/var/tmp/sparse bs=2048k seek=1

where you will see the original file is just a few dozen bytes, the result with ls -l or wc -c shows a 2 meg file, but du(1) will show the file as occupying just a bit more than the original /etc/issue file. A cp(1) of the file will create a new file that is the same size (using ls -l or wc -c) but du(1) will now show a MUCH larger size than the original file.

A common file that is often sparse is a core file from a crashed program. Another file that might be sparse is /etc/mail/aliases.pag. And of course, any programmer could write special code that creates a sparse file.

Now to troubleshoot your / filesystem, use du as in:

du -kx / | sort -rn | head

Look for big directories at the top of the list. This is fairly normal:

35855 /
18926 /sbin
14000 /etc
6811 /etc/opt

NEVER allow non-HP-UX directories to exist in the / filesystem (mountpoints are fine). This is what is causing your problems with /. The / directory NEVER grows unless you have junk stored there, or a bad application created a non-mountpoint directory there.

Look for big files with:

ll /sbin | sort -rnk5 | more

In your case, sorting the du listing produces:
31052 /
19085 /sbin
11301 /etc
4665 /etc/lvmconf
4235 /etc/opt
4125 /etc/opt/resmon
3684 /sbin/fs

which is normal. So you likely have some rogue process that has created a temp file which is still open and will disappear when the system reboots.

[Volker Borowski]

Hi,

always good for eating up space in / :

/dev/rmt/mistyped_tape_device
find / -name 'core'
find / -name 'utmp'
find / -name 'wtmp'
/tmp not beinig a sepearate filesystem

First guys to be checked
Good hunting
Volker

[sycncs]

Hi there

Bdf will reflect the total usage space, including the space that it is actually being in use as well as old files that is taking up the space, even when the links are lost.

To see the actual space used, got to lvol3, do du -sk ./
The difference you get from doing a "bdf" is the amount of space that is being used in the past but were not removed properly.

To correct this problem, you could umount lvol3 and mount again. Or, a reboot would also do the job.

Hope this helps.

[Thayanidhi]

Hi,

When you mount a fileystem to mountpoint the files(if any) exists on the mountpoint will be hidden. unmount the file systems and check whether any application created file to mount points instead to file systems.

Though the files are not seen but still space is occupied.

Just a thought
TT

[Steven E. Protter]

If you have tried this and still can't figure things out, learn from one of my mistakes.

Lets say you unmount the /opt filesystem for some reason.

then you forget and copy 100 MB of files to that folder. Remember, a filesystem is mounted "on" a folder.

Then you reboot the system, or remember and type mount /opt

Life is good right, except now you've got an extra 100 MB in the root filesystem. You can't find it either, because when the directory is used to mount a filesystem, its contents are hidden.

So a possible investigatory path is to unmount the affected filesystem, cd to its directory and see if anything is there that does not belong.

I've run into this a few times, once by my own hand, another time when the /var filesytem got corrupted and the system kept trying to write stuff there after I unmounted it.

It's insidious.

As far as increasing the root fileystem, / I used an ignite backup. You can boot off it and iterupt the process and expand root, so long as there is adequate space on the disk. The root filesytem must be contiguous btw

On older systems that are tight on space, I've taken to keeping a 50 Meg slug file on the disk. Why? Because if the fs fills up and its not obvious, I can get back 50 Meg with a quick delete command. Then I have breathing room to track the actual problem.

The last two times the / fs got full on my systems the group and or the passwd file was changed to zero length.

That REALLY sucked.

I hope the reason it sucked is obvioius.

Steve

[James Odak]

is the fs HFS?
something a tech told me a while back
BDF on HFS fs will not report all the space as free ..it reserves a certain amount of space that can only be used by root and can show your fs as full when it is not nessesarily full

situation that it happened to me ..user tried to write a backup to a device that did not exist ..so there fore the data of the backup filled into /dev/rmt/1m as a file not a device ... was writen with the users id system alerted / was full and whne i check it, it didnt report totaly full (but more then usual)

my favorite command when investigating full fs
find / -xdev -size +1000 -depth -print

good luck

[Jochen Heuer]

Check for unlinked (removed but still held open) files also:

$ lsof +aL1 /

lsof can be found on the net. Check thread '/var is full' for download sites ...

[Jose Mosquera]

Hi,

This will be you useful:

du / -akx|sort -nr|more

Rgds.

[John Meissner]

have you tried looking for core files under / ?