Solaris

Um, rebooting and making "/proc going to normal again" is flawed reasoning and not sound advice technically. /proc appears to grow larger as your machine runs because it contains a representation of running applications memory (NOT DISK) space. So, rebooting makes /proc smaller because you're no longer running those applications. As soon as you start running applications again, /proc will grow as memory gets addressed. This is normal behavior!

>>> /proc has nothing whatsoever to do with disk space. <<<

Side note: don't reboot Unix machines arbitrarily, it makes Unix admins sad.

Thanks again

After you reboot your machine /proc capacity wil be 0%.


Best Regards

Bejo

I am having the similar problem too. proc and dev have taken up huge amount of the space. Will a reboot clear dev too? Currently /home2, 3 and 4 are on different slices.

Code:

0	du.txt
0	home
0	net
0	vol
1	bin
1	cdrom
1	export
1	home10
1	home11
1	mnt
8	lost+found
9	home1
12	INFORMIXTMP
26	hdir
88	tmp
112	axinstall26
147	devices
207	boot
1511	sbin
4838	InstallShield
13565	system
31314	lib
31823	test0515
41856	kernel
63447	etc
255356	platform
2033773	opt
2048006	var
3366136	usr
4180789	opt2
12337612	home4
12798104	home2
17410368	home3
17452416	dev
20503084	proc

I guess that I will try one more time... /proc is an illusion. It does not actually consume disk space.

If you create a new process with, say pid 1234 and it is using 300 MB of memory, /proc/1234 will magicly pop into existence and it will be 300 MB in size. But you did not lose any disk space. Not one byte.

Now, kill pid 1234 and /proc/1234 will vanish. But you won't get back even one byte of disk space. /proc/1234 is just a way to treat a process as if it was a data file. This makes stuff like debuggers very easy to write.

/dev, on the other hand, is probably a real problem. It is usually caused by someone doing something like:
tar cvf /dev/wrong-name-for-tape-drive /big/collection/of/files

Maybe:
find /dev -type f
will find it for you.

Hola,
i have found the culprit leading to high root usage. /dev/rmt/0n has taken huge amount of disk space.

Things have went back to normal now! Thanks for your 'clue'. =)