![]() |
|
|
|
|
|||||||
| Forums | Portal | Register | Forum Rules | FAQ | Contribute | Members List | Arcade | Search | Today's Posts | Mark Forums Read |
| UNIX for Advanced & Expert Users Advanced UNIX and Linux questions go here. Expert-to-Expert. |
|
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| /tmp full | rainbow_bean | AIX | 3 | 12-13-2007 02:24 PM |
| when 100% full, it says some available | hcclnoodles | SUN Solaris | 1 | 01-02-2007 10:46 AM |
| pls help - /dev/dsk 100% full | indianboy08 | SUN Solaris | 1 | 03-12-2006 07:46 AM |
| /tmp full | pascalbout | AIX | 9 | 02-17-2006 10:39 AM |
| /usr is full | D-Lexy | Filesystems, Disks and Memory | 7 | 06-17-2002 01:44 PM |
|
|
Submit Tools | LinkBack | Thread Tools | Search this Thread | Display Modes |
|
#1
|
|||
|
|||
|
/ is full
Hi Exprts,
I faced this problem several times, which / file system is full (near 100%) and "proc" under that is the main reason. i don't know how to reduce the size as all directories under proc seems important & other dir/files under / are OS related & could not be removed. could anyone advise me for the possible solutions on making the / file system free. Thanks, --nikk |
| Forum Sponsor | ||
|
|
|
#2
|
||||
|
||||
|
Type "df -k" and look at the result. Removing files in other filesystems won't help if / is full. You've got to remove stuff in the root filesystem. Note that /proc is a separate filesystem. That right there should tell you that looking at /proc is barking up the wrong tree. What's worse is trhat /proc consumes no disk space at all. It's a psuedo filesystem. Psuedo means make-believe. So ignore /proc and the other filesystems...if root is full, you've got to address that by looking at root.
If root has filled it's because someone wrote some files there. So a reasonable approach is to look at a recently written files in root... find / -mount -mtime -10 -type f -print | xargs ls -l The -mtime -10 says written to less than 10 days ago. You may need to adjust that. |
|
#3
|
|||
|
|||
|
If proc does not use any space so the only thing which remains are opt,platform,... which are OS related & does not grow daily.
I didn't consider other files in different file systems & the only thing i focused is whatever i could remove directly under / which is nothing. - could any other reason cause the size growth of / ? - In addition if i want to add space to / what should i do? Rgrds, nikk |
|
#4
|
|||
|
|||
|
What about /var? Is it it's own filesystem, or is it part of the root filesystem.
Can you post the output of df -k Did you try Perderabo's find command? |
|
#5
|
||||
|
||||
|
Nikk...
You need to list your filesystems with sizes... /(root) /var /usr /opt /home /stand Most likely these are not under the Filesystem / and should not be imho, but can be on the same disk as /. My advice is to look for any devices in / that you may have inadvertently created a tar and > it to a device name instead of > to a tape device... I ahve seen it where folks do this: tar -cvf ... ... > /dev/rmt/0mn or similar to a disk device by accident... Try this command in / du -k |sort -rn then go to the dirs under / that are large and narrow down where the large files are located....
__________________
My brain is your brain |
|
#6
|
|||
|
|||
|
Kelam,
I found out the reason, under /dev one link was created like (rmt0 -> /dev/rmt/....) which was not a right link & i removed that, i don't know how it had been created cause the client are not familliar to run any unix command. One more thing was .CPR which had very large size, i executed cat /dev/null >.CPR to make its size zero. now / is ok. Thanks, --Nikk |
|
#7
|
|||
|
|||
|
Yes, I think since /proc is a pseudo, it's always 100%. Also, core dumps are occasionally dumped to / . They can be very large. Depending on your distro, you can select a different filesystem to write core dumps, automatically delete them, or set conditional space rules.
|
|||
| Google The UNIX and Linux Forums |