understand usage of a partition

M

m4rtin

Usage of my /dev/ad6s1a partition (mounted on /) is 108%:

Code: 
[root@ ~]# df -hiT
Filesystem   Type     Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/ad6s1a  ufs      496M    491M    -35M   108%    3.9k   62k    6%   /
devfs        devfs    1.0K    1.0K      0B   100%       0     0  100%   /dev
/dev/ad6s1e  ufs      496M    1.2M    455M     0%      83   66k    0%   /tmp
/dev/ad6s1f  ufs       70G     18G     46G    28%    731k  8.7M    8%   /usr
/dev/ad6s1d  ufs      1.9G    120M    1.6G     7%    7.7k  251k    3%   /var
[root@ ~]#

However, I have difficulties to understand what is occupying the space on the / directory :\ As I understand those need to be files not in the directories /dev, /tmp, /usr and /var? If so, I constructed following search pattern:

Code: 
[root@ ~]# find / \( -path /dev -o -path /tmp -o -path /usr -o -path /var \) -prune -o -size +1M -print
/boot/kernel/kernel
/boot/kernel/kernel.symbols
/boot/kernel/acpi.ko.symbols
/boot/kernel/if_ath.ko.symbols
/boot/kernel/ispfw.ko
/boot/kernel/wlan.ko.symbols
/boot/kernel/xfs.ko.symbols
/boot/kernel/zfs.ko
/boot/kernel/zfs.ko.symbols
/lib/libc.so.7
/lib/libzpool.so.2
/lib/libcrypto.so.6
/rescue/rescue
/rescue/cat
/rescue/chflags
/rescue/chio
/rescue/chmod
/rescue/cp
/rescue/date
/rescue/dd
/rescue/df
/rescue/echo
/rescue/ed
/rescue/red
/rescue/expr
/rescue/getfacl
/rescue/hostname
/rescue/kenv
/rescue/kill
/rescue/ln
/rescue/link
/rescue/ls
/rescue/mkdir
/rescue/mv
/rescue/pkill
/rescue/pgrep
/rescue/ps
/rescue/pwd
/rescue/realpath
/rescue/rm
/rescue/unlink
/rescue/rmdir
/rescue/setfacl
/rescue/sh
/rescue/stty
/rescue/sync
/rescue/test
/rescue/[
/rescue/rcp
/rescue/csh
/rescue/tcsh
/rescue/atacontrol
/rescue/badsect
/rescue/camcontrol
/rescue/ccdconfig
/rescue/clri
/rescue/devfs
/rescue/dmesg
/rescue/dump
/rescue/rdump
/rescue/dumpfs
/rescue/dumpon
/rescue/fsck
/rescue/fsck_ffs
/rescue/fsck_4.2bsd
/rescue/fsck_ufs
/rescue/fsck_msdosfs
/rescue/fsdb
/rescue/fsirand
/rescue/gbde
/rescue/geom
/rescue/glabel
/rescue/gpart
/rescue/ifconfig
/rescue/init
/rescue/kldconfig
/rescue/kldload
/rescue/kldstat
/rescue/kldunload
/rescue/ldconfig
/rescue/md5
/rescue/mdconfig
/rescue/mdmfs
/rescue/mknod
/rescue/mount
/rescue/mount_cd9660
/rescue/mount_msdosfs
/rescue/mount_nfs
/rescue/mount_ntfs
/rescue/mount_nullfs
/rescue/mount_udf
/rescue/mount_unionfs
/rescue/newfs
/rescue/newfs_msdos
/rescue/nos-tun
/rescue/ping
/rescue/reboot
/rescue/fastboot
/rescue/halt
/rescue/fasthalt
/rescue/restore
/rescue/rrestore
/rescue/rcorder
/rescue/route
/rescue/routed
/rescue/rtquery
/rescue/rtsol
/rescue/savecore
/rescue/spppcontrol
/rescue/swapon
/rescue/sysctl
/rescue/tunefs
/rescue/umount
/rescue/atmconfig
/rescue/ping6
/rescue/ipf
/rescue/zfs
/rescue/zpool
/rescue/bsdlabel
/rescue/disklabel
/rescue/sconfig
/rescue/fdisk
/rescue/dhclient
/rescue/head
/rescue/mt
/rescue/sed
/rescue/tail
/rescue/tee
/rescue/gzip
/rescue/gunzip
/rescue/gzcat
/rescue/zcat
/rescue/bzip2
/rescue/bunzip2
/rescue/bzcat
/rescue/tar
/rescue/vi
/rescue/ex
/rescue/id
/rescue/groups
/rescue/whoami
/rescue/chroot
/rescue/chown
/rescue/chgrp
/root/ping.core
/root/nuttcp_deltas
/root/Ocsinventory-Agent-2.0.tar.gz
/root/.cpan/Metadata
/iperf.core
[root@ ~]#

Majority of larger files are in the /rescue directory. Should I delete the content of the /rescue directory? Any other techniques to find out what exactly occupies the / directory as there aren't any large files there? :OOO
 
You can delete the *.symbols files, they are only useful for kernel debugging. Do not delete /rescue, the files are all one single file with multiple hard links to the file, they are only taking the space of one copy.

The partition for / is on the small side, probably created with quite old version of sysinstall(8) that didn't reserve enough room for /. The newer installers (I think starting with 8.2 or was it 8-STABLE) reserve at least 1GB for the root partition.
 
That find is not quite doing as intended.

The files in /rescue are really all the same file, see rescue(8). The size of / was increased in recent installers because 512M was more than half filled by a kernel build. This should give a better idea:
# du -kxd 1 /
 
kpa said:
You can delete the *.symbols files, they are only useful for kernel debugging. Do not delete /rescue, the files are all one single file with multiple hard links to the file, they are only taking the space of one copy.
Click to expand...
Ok, I see. So /rescue directory actually contains only one file which contains static links crunched to a binary? Is it possible to detect this without documentation? # du -h /rescue/ ..is probably one possibility as du doesn't follow symbolic links by default.

kpa said:
The partition for / is on the small side, probably created with quite old version of sysinstall(8) that didn't reserve enough room for /. The newer installers (I think starting with 8.2 or was it 8-STABLE) reserve at least 1GB for the root partition.
Click to expand...

Yes, I'm running FreeBSD 8.0.


wblock@ said:
That find is not quite doing as intended.
Click to expand...
Idea was to find all the large(>1MB) files in directories which make up the /, but exclude /tmp, /usr and /var as they have own partition.


wblock@ said:
This should give a better idea:
# du -kxd 1 /
Click to expand...

Output if following:

Code: 
[root@ ~]# du -xhd 1 /
2.0K	/.snap
512B	/dev
2.0K	/tmp
2.0K	/usr
2.0K	/var
1.7M	/etc
2.0K	/cdrom
2.0K	/dist
1.0M	/bin
144M	/boot
6.7M	/lib
242K	/libexec
4.0K	/media
4.0K	/mnt
2.0K	/proc
4.0M	/rescue
 38M	/root
4.0M	/sbin
2.0K	/tftpboot
200M	/
[root@ ~]#

Am I correct, that -x means that /tmp, /usr and /var are not analyzed as they have their own mount points?
 
m4rtin said:
Is it possible to detect this without documentation?
Click to expand...
[cmd=]ls -li /rescue[/cmd]

Will show almost all files share the same inode, i.e. they are the same file.
 
m4rtin said:
Idea was to find all the large(>1MB) files in directories which make up the /, but exclude /tmp, /usr and /var as they have own partition.
Click to expand...

Possibly I'm misreading it, but it looked like a -not was left out.

Am I correct, that -x means that /tmp, /usr and /var are not analyzed as they have their own mount points?
Click to expand...

Yes.
 
Any ideas why size of / content does not match with df output for / (187MB vs 496MB):

Code: 
[root@martin ~]# df -hT /
Filesystem   Type    Size    Used   Avail Capacity  Mounted on
/dev/ad6s1a  ufs     496M    489M    -33M   107%    /
[root@martin ~]# du -xhd 1 /
2.0K	/.snap
512B	/dev
6.0K	/tmp
2.0K	/usr
2.0K	/var
1.7M	/etc
2.0K	/cdrom
2.0K	/dist
1.0M	/bin
144M	/boot
6.7M	/lib
242K	/libexec
4.0K	/media
4.0K	/mnt
  0B	/proc
4.0M	/rescue
 25M	/root
4.0M	/sbin
2.0K	/tftpboot
187M	/
[root@martin ~]#
 
You are trying to find files on ad6s1a, /, correct ?

Do the simple find like this:

# find / -xdev -size +10000 -exec ls -la {} \;

Notice the -xdev option (you can use -x too, it's the alias). This way find won't traverse to different FS (don't descent to directories with different device number than the one search originated).

Also -mtime is a good option if the FS was fulled recently. E.g. find files older than a 3 days on slash:

# find / -xdev -type f -mtime +3 -exec ls -la {} \;

You can combine it with size option to get some reasonable results.
 
wblock@ said:
Possibly I'm misreading it, but it looked like a -not was left out.
Click to expand...

I used -prune keyword for paths which contain /dev, /tmp, /usr or /var which should mean that find doesn't descend into those directories.


matoatlantis said:
You are trying to find files on ad6s1a, /, correct ?

Do the simple find like this:

# find / -xdev -size +10000 -exec ls -la {} \;

Notice the -xdev option (you can use -x too, it's the alias). This way find won't traverse to different FS (don't descent to directories with different device number than the one search originated).

Also -mtime is a good option if the FS was fulled recently. E.g. find files older than a 3 days on slash:

# find / -xdev -type f -mtime +3 -exec ls -la {} \;

You can combine it with size option to get some reasonable results.
Click to expand...

Yes, I'm trying to understand what causes high disk usage on ad6s1a partition. Results for [cmd=]find / -xdev -size +4M -exec ls -lha {} \[/cmd]

Code: 
[root@martin ~]# find / -xdev -size +4M -exec ls -lha {} \;
-r-xr-xr-x  1 root  wheel    11M Nov 21  2009 /boot/kernel/kernel
-r-xr-xr-x  1 root  wheel    35M Nov 21  2009 /boot/kernel/kernel.symbols
-r-xr-xr-x  1 root  wheel   4.3M Nov 21  2009 /boot/kernel/zfs.ko.symbols
-rw-r--r--  1 root  wheel    15M Jun  6  2011 /root/.cpan/Metadata
[root@martin ~]#

As you can see, there are no large files on this partition. And still, shouldn't the [cmd=]df -hT /[/cmd] and [cmd=]du -xhd 1 /[/cmd] have the same result? :OOO
 
Well, this kind of behavior is typical when you have removed the file that was still opened by some process. This would be fixed upon next umount/mount (reboot in your case).

You can try to search with fuser or sysutils/lsof for opened files - this way you can get an idea what files are opened (and compare if they exist).

For example:

# lsof /

Would give you a list of opened files. Depending what currently runs on the system, this can be a huge list though.
 
matoatlantis said:
Well, this kind of behavior is typical when you have removed the file that was still opened by some process. This would be fixed upon next umount/mount (reboot in your case).

You can try to search with fuser or sysutils/lsof for opened files - this way you can get an idea what files are opened (and compare if they exist).

For example:

# lsof /

Would give you a list of opened files. Depending what currently runs on the system, this can be a huge list though.
Click to expand...

Yes, this can be possible as my machine has been running more than a year for now without unmounting file-systems. I finally searched for files which have link count of zero:

Code: 
lsof +L1 | sort -nk7

..and killed those processes (mostly tcpdump -w filename). At the moment situation is fine:

Code: 
[root@martin ~]# df -h /
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad6s1a    496M    187M    269M    41%    /
[root@martint ~]# du -shx /
187M    /
[root@martin ~]#

As I understand, du searches recursively files from folders and checks for the size of those files. However, how does df work? Does it analyze file-system metadata? :OOO
 
m4rtin said:
I used -prune keyword for paths which contain /dev, /tmp, /usr or /var which should mean that find doesn't descend into those directories.
Click to expand...

I just glanced at your response before; I see now you tried to use prune.

That's not what it's used for. To not to write too much, observe the following behavior:

# mkdir -p /an/empty/one/too
# mkdir -p /a/new/directory
# find /a /an -type d
Code: 
/a
/a/new
/a/new/directory
/an
/an/empty
/an/empty/one
/an/empty/one/too

And now with prune:

# find /a /an -type d -prune
Code: 
/a
/an

prune doesn't mean it wont go through those directories, it just means it wont traverse them.

There can be some fun to specify directories to skip under the same filesystem (find doesn't behave the same on all UX/UX-like platforms), but that's not what you were trying to solve here.
 
You must log in or register to reply here.
Back
Top