/ is full

[Jeff Hagstrom]

/dev/vg00/lvol3 1024000 1023992 8 100% /

My / "slash" directory is full 100%. What could be growing in slash to cause it to fill up? What can I remove or shorten to get space back?

[Ivan Krastev]

Search for core files. Search for last modified files.

regards,
ivan

[James R. Ferguson]

Hi:

Probably the most common cause of this is a regular file in the device ('/dev') directory from a mis-typed backup like:

/dev/rmt/om

...note the "o" and not the "0".

Do:

# ls -lR /dev|grep "^-"

...and see what (if anything) turns up.

Also, see where your space has been consumed by doing :

# du -kx / | sort -k1,1rn

...the majority of the utilization should be in '/etc' and '/sbin'.

Regards!

...JRF...

[Ganesan R]

Hi,

Check which dir consumes more space by,

#du -xk / |sort -nr |head -25

Check in /dev diretory if anyone used wrong device files(om instead of 1m)

Find large files in root.(size more than 50MB)

# find / -size +50000 -xdev -exec ll {} \;

Find if any core files and delete.

# find / -name core -print

[SKR_1]

Find the latest written files on FS.

find / -xdev -size +1000000c -exec ll {} \;
du -sk / | sort -n

If you dont have nothing to remove, then you need to go for ignite boot of the server and resize the root FS.

Thanks

SKR

[OFC_EDM]

If you posted the output of bdf it would give us an idea of how your mount points are setup.

Then would be better able to advise what you could "remove".

If you're setup in a standard fashion there won't be much if anything you could remove.

Other than finding a file that grew due to the reasons already posted.

[Jeff Hagstrom]

bdf display

[OFC_EDM]

I was hoping to find something non-standard.
Once saw a person have /var under root. Which caused their problems with /, root not slash, :) filling up

Looks like following the advice of the above posts is the way to go.

Regards

[John Guster]

I would cd /, do a list to check first any core, *.tar files. can you post output of ll /?

[James R. Ferguson]

Hi (again) Jeff:

Well, what have you tried and what were your findings thus far?

...JRF...

[TTr]

This thread is very recent and from about 4th response down it shows a very good approach on cleaning up the root filesystem

http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1276884

[Manas Mangal]

please check for core file in /
cd /
ls -l core*
i think this will solve your issue .
else find with du command .

[Jeff Hagstrom]

It turned out to be a file system that didnt' get mounted that we were writing out to.

We had to restore from an ignite tape from another box. And when he mapped in the volume groups and file systems, he missed that one.

[Jeff Hagstrom]

I still am having a space issue on "/". I can't print, I can't save a file the "/" directory. In /dev there were some printer files that were pretty big. I moved them and it didn't help the space issue. I'm still stuck waiting for my support provider to call me back cause they can't figure it out.

[Tim Nelson]

>>I still am having a space issue on "/". I can't print, I can't save a file the "/" directory. In /dev there were some printer files that were pretty big. I moved them and it didn't help the space issue. I'm still stuck waiting for my support provider to call me back cause they can't figure it out.

Not sure what these were but my first guess is that these "big printer files" are still open in memory.

In order to recover the space still allocated in RAM and not reflected from a filesystem point of view you either need to stop/kill those processes holding open the files or even better reboot the system as mostlikley your next comment will be that you cannot stop the application. Either way you will have to take an outage.

[Rory Hammond]

If you have a file that is still open and did a move or delete. The space will not be free until the process that has the file open is killed.


all the suggestion given were good. I also suggest you use "lsof" to see if you have any lost open files

[Grayh]

i think the log entries on one of the following logs would also be helpful to diagnose the issue

var/adm/syslog/syslog.log
event.log
dmesg

probably you will find something there

[Tom Henning]

The other possibility is that you did not remove the files under the mount point when you mounted the missing directory. If this is the case then the files are still taking up space on the root volume, and you need to umount the filesystem and clean out the files under the mount point directory to reclam space.

[Dennis Handly]

>Tom: you need to umount the filesystem and clean out the files under the mount point directory

You don't need to unmount it. What you could do is export the directory under the mount point and if you have RW access, you can remove those files.

[Tom Henning]

Dennis Handy Stated:

You don't need to unmount it. What you could do is export the directory under the mount point and if you have RW access, you can remove those files.

------------

Sorry Dennis, I'm not certain I follow you. I was under the impression that if you exported a directory, which was a mounted volume, the remote system saw the contents of the mount point, not the directory under the mount point. Could you provide more detail on how to "export the directory under the mount point" without unmounting the file system first?

[AwadheshPandey]

I came late but have an idea which will definatly work.

Pls create a file just before your fs got full by touch -t time stamp /REF_FILE

for example
touch -t 200810201235 /REF_FILE

search for newer files wrt REF_FILE for all directories of / file system.

find DIRNAME -type f -newer /REF_FILE

re-view the files and remove if not required.

Cheers,

Awadhesh

[Dennis Handly]

>Tom: I was under the impression that if you exported a directory, which was a mounted volume, the remote system saw the contents of the mount point, not the directory under the mount point.

I may have been talking about the mount point under an NFS mount point, not a local filesystem. Since you can't daisy chain export NFS, you get the one underneath.

>Could you provide more detail on how to "export the directory under the mount point" without unmounting the file system first?

Hmm, it seems to be not very easy.
Anyway, if you want to get underneath a NFS mount point, you can't just put the that in exportfs:
exportfs error: /var/tmp/FILER3: Too many levels of remote in path

But if you put /var/tmp there, you can then look at that, then go into FILER3.
mymachine:/var/tmp /var/tmp/FILER3_under nfs

So look at /var/tmp/FILER3_under/FILER3.