The Solaris group is a forum where peers share technical expertise, solve problems, and discuss issues related to the Solaris operating system, including OS-related malfunctions, security issues, and network performance.

Don't forget the basics, that are easy to overlook, check for "files" in
/dev directories that were intended for a device (a typo in the device name
created a file for you instead of output to the device) and files copied to
a directory that is used as a mount point when that file system is "not"
mounted will take up space but not be "visible" to you until you unmount
that file system.

Help the community by fixing grammatical or spelling errors, summarizing or clarifying the solution, and adding supporting information or resources. Always respect the original author.

Popular White Paper On This Topic

Don't forget the basics, that are easy to overlook, check for "files" in
/dev directories that were intended for a device (a typo in the device name
created a file for you instead of output to the device) and files copied to
a directory that is used as a mount point when that file system is "not"
mounted will take up space but not be "visible" to you until you unmount
that file system.

Hi
Before taking any step for increasing root file system size just check any
logs are generated if not then follow the following steps
1)get ur root filesystem under root SVM control or Veritas control
2)create one more subdisk or a slice and attach the root slice to the newly
created one
3)then run growfs command.
Please let me know if there is any other alternative method
Thanks And Regards
Nitesh Bhope
Unix Administrator
WILSHIRE SOFTWARE TECHNOLOGIES

This is not a simple situation, sometimes your root fs has suddenly reached
%100 , then your application is still up, and you dont want to downtime
because of that, if you are lucky du command still can be run, you have to
check df -h output, if your mount /var/opt ,/export /usr mount points on
the root fs, first of all check them all with du -sh * command, but if you
can not run command try to go single user mode with -sw, or boot from
cdrom.. or if you can run find command try to find out which file is gaining
hugest size on the filesystem
as an example, below notation will bring file which is greater den 100mb and
under /var directory.

1) Can you copy all /var/adm/messages# to other remote server and redirect
all /var/adm/messages# file to null device.

2) If you taken backup from tape drive that time if u given wrong syntax of
tape drive that back copy store itself on server this may be a cause to full
root filesystem. for that check in to /dev/rmt# directory using ls -ltr.

What I am meaning as beware is that the example quoted using find on / (the root filesystem) will cross filesystem boundaries for any filesystem that is mounted on a different place. A basic Solaris concept. For example if you have a filesystem on a disk which is mounted on /var then anything that is in this filesystem will NOT be on the same disc as the root partition. The find command quoted though will walk over /var and find it. That is why you use -mount as an argument to find which means that it does not walk over filesystem boundaries. Use man find for further info on this.

To find the top ten files by size on the root partition I would execute the following:

$ sudo find / -ls -mount | sort -k7n,7n | tail

Your mileage may vary (and, of course, if you are already root you won't need the sudo, but if you are doing a walk over the root partition you will likely need root privilege). You'll probably find some files that you didn't realise were getting big (and maybe ones that you didn't realise were on the root partition).

All the advice about /var/crash etc you read elsewhere is good too. You really don't want to be dumping cores (and logs) on the root partition as getting it to 100% is a BAD idea.

Nowadays however you are finding some sysadmins that reckon on only one filesystem, just have it BIG. I suppose I can grudgingly see the attraction on that.

I can't help but laugh at this problem for it underscores perhaps the biggest difference between HP-UX and Solaris administration. Solaris admins for some UNIX caveman reason that was passed down to them from the first forms of UNIX speak, (* grep! awk! sed! Ugh! Help me my root is full! What do I do? What do I do? *), still, don't know how to build volumes and extra mount points. Its been over a decade since 2 and 4 GB disks so why continue?

Is the volume manager problems? UFS cylinders in 5, disksuite in 6, VXVM in 7, 8 and 9 and now, SVM (* AKA glorified Disksuite *) in 10? You know they went back to disksuite to rid themselves of the Veritas licensing costs their customers were screaming about? But my God, what a standardization problem! Having to learn a new volume manager command set every year.

This is what Solaris does: (/) root volume is 15 GB and up! I saw one Solaris box sized to take up the whole disk and it was over 150 GB.

Really sloppy work. No discipline whatsoever.

Here's what HP-UX did many years ago: Any dir bigger than a Gig like /opt, /usr, /home, /tmp, /var/crash, /var/tmp fits nicely into it's own logical volume and obsoletes procedures like, 1) move log files from (/) root like /var/adm/messages.0-9 into another spare volume which is not apart of the OS but still might be needed at a later time.

That's what tape backups are for. Not log files.

At the time of installation your goal should be to keep (/) root down to about 500 MB or may even 1 GB but no bigger. When you do this then when root fills up it comes down to basically to commands:

du -k / | sort -rn | head 20, and,

touch somefile
find / -newer somefile

'du' should be obvious. Not so obvious is the find command which searches for runaway processes. It does this by checking the time stamp of 'somefile' against anything older than 'somefile'.

PS: Don't you guys think the find command becomes unusable when root is so big and therefore basically useless at 150 GB?

One hidden aspect of your commands is that the -size +200000 option uses default units - normally 512-byte blocks. There are various extensions that specify sizes. Both the default block and the extensions may vary between OS.

For actual byte sizes, use -size +300000c and so on. For megabytes, check if your local system uses e.g. -size +15M

Also, be aware the + is a very important operator in find. If you check for -size 200000, you are asking to report only files of exactly 200000 blocks.