Hi all
I am facing high utilization of my root partition. below is the output of df -h
bash-3.00# df -h
Filesystem size used avail capacity Mounted on
/dev/md/dsk/d10 9.9G 9.4G 406M 96% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 15G 1.5M 15G 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
/platform/SUNW,Netra-T2000/lib/libc_psr/libc_psr_hwcap1.so.1
9.9G 9.4G 406M 96% /platform/sun4v/lib/libc_psr.so.1
/platform/SUNW,Netra-T2000/lib/sparcv9/libc_psr/libc_psr_hwcap1.so.1
9.9G 9.4G 406M 96% /platform/sun4v/lib/sparcv9/libc_psr.so.1
fd 0K 0K 0K 0% /dev/fd
swap 15G 34M 15G 1% /tmp
swap 15G 32K 15G 1% /var/run
/dev/md/dsk/d30 54G 19G 35G 35% /opt
home 54G 14G 40G 26% /home
As you can see Filesystem /dev/md/dsk/d10 mounted on / is 96% utilized. how can i view the detailed utilization of this device only. if i use du -sh /* i get utilization of complete system i guess around 440GB.
How can i get stats for /dev/md/dsk/d10 only.
Thanks for the help.
From du man page:
-x
When evaluating file sizes, evaluate only those files that have the same device as the file specified by the file operand.
So this should work:
du -shx /
Thanks for the reply bartus11 i tried this in two ways and here is the output:
bash-3.00# /usr/xpg4/bin/du -shx /
3.0G
this was confusing so i tried it with /*
bash-3.00# /usr/xpg4/bin/du -shx /*
1K /bin
1K /cdrom
761K /dev
142K /devices
59M /etc
1K /export
1K /gconfd-root
14G /home
37M /kernel
29M /lib
15K /log.dev
8K /lost+found
1K /mnt
0K /net
18G /opt
1K /orbit-root
12M /platform
85G /proc
3K /rmdisk
1.3M /sbin
1K /system
35M /tmp
0K /usage4.txt
2.5G /usr
281M /var
0K /vol
now i am even more confused 
. The first one says 3.0G and shows no details Utilization is 9.4G. the second command shows 85G for /proc alone 
.
What to do?
Try:
du -hx /
Don't use /*, as it will expand to filesystems like /opt or /home.
I suspect three gigs is correct for /usr/xpg4/bin/du -shx / -- for existing files anyway. There could well be many gigs of deleted files still on the disk: The filenames are gone, but the file still exists because something had it open, it'll only truly be deleted when they close.
I see you have no /var/ partition, so your logfiles were ending up in the root partition itself. If someone went and deleted your logfiles instead of truncating them, any loggers that had them open would continue happily using the deleted files.
A reboot may fix it, or you could try and track it down with fuser and restart the affected services.
Thanks Corona and Bartus. Yeah i Believe Corona you are correct cause thats the thought that has been troubling me. Here is the output of du without -s
/usr/xpg4/bin/du -hx /
8K /lost+found
2K /var/sadm/install/admin
3K /var/sadm/install/logs
16M /var/sadm/install
2K /var/sadm/pkg/SUNWocfd/install
2K /var/sadm/pkg/SUNWocfd/save/pspool/SUNWocfd/install
8K /var/sadm/pkg/SUNWocfd/save/pspool/SUNWocfd
9K /var/sadm/pkg/SUNWocfd/save/pspool
.
.
.
.
1K /rmdisk/unnamed_rmdisk
3K /rmdisk
2K /.ssh
1K /orbit-root
1K /gconfd-root
3.0G
Once again Final output 3.0G. How do i use *fuser* to track the culprits?
Start by identifying the log files that are in use on your host.
Most people use /etc/logadm.conf to manage log rotation, although sometimes scripts are written for "quick & dirty" log truncation. Check /var/spool/cron/crontabs for entries that might be performing inappropriate log pruning...
Some applications (like apache) have their own log rotation mechanisms - you may want to check these as well to ensure that they aren't broken in some fashion.
If you can resolve your log rotation issues correctly, you can force them to rotate and release any "empty" space.
Thanks avronis. Yeah I think the act needs to be cleaned up, but is there someway to quickly redeem this loose space, dangling pointers etc. Without machine reboot or partition remounting.
Someway to flush the memory.
It's not stuff that hasn't been flushed -- the deleted files are literally still in use. Deleting the file doesn't do anything to something that already has the file open -- the file continues to exist, and won't be released from disk until whatever's holding them open lets them close.
lsof doesn't seem to be able to give file names, but you can ask it for every process using / with fuser -v -M /
Quickest and dirtiest way: reboot the system.
you can try that below:
du -ks /* |sort -nr
Hi all
Thanks for the guidance. I ended up rebooting the machine on the weekend because the situation was getting out of hand and good to say i can see the utilization is now down to 3GB as per our "du" output :).
I have now come across a sun script
nfsfind
would this work to close deleted files still held open by processes?
As long as the file is open by a process, there is no way it can be closed. The file is closed when the application that holds it closes the file, which is usually when the application quits.
pfiles
The pfilescommand could be used to check which files are open by an application. For files that are delete, pfiles will only list file information but no file name. But be aware. Not all files listed by pfiles without a file name are errors and/or problems that need to be fixed.
$ pfiles 19547
19547: /usr/bin/perl ./keepopen
Current rlimit: 256 file descriptors
0: S_IFCHR mode:0620 dev:298,0 ino:12582934 uid:0 gid:7 rdev:24,9
O_RDWR|O_LARGEFILE
/devices/pseudo/pts@0:9
1: S_IFCHR mode:0620 dev:298,0 ino:12582934 uid:0 gid:7 rdev:24,9
O_RDWR|O_LARGEFILE
/devices/pseudo/pts@0:9
2: S_IFCHR mode:0620 dev:298,0 ino:12582934 uid:0 gid:7 rdev:24,9
O_RDWR|O_LARGEFILE
/devices/pseudo/pts@0:9
3: S_IFREG mode:0644 dev:136,3 ino:79343 uid:0 gid:0 size:222173910
O_RDONLY|O_LARGEFILE FD_CLOEXEC
Doesn't sound related, no.
To close the file you either have to convince the application to close it, or kill the application.
The former would be nicer if you can do it. If it's system logs, a SIGHUP to the right daemon might do.
You can get a version of lsof for Solaris from sunfreeware which hopefully provides more illuminating output than fuser.