# understand usage of a partition



## m4rtin (Feb 14, 2012)

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


```
[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:


```
[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


----------



## kpa (Feb 14, 2012)

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.


----------



## wblock@ (Feb 14, 2012)

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 /`


----------



## m4rtin (Feb 14, 2012)

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.


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.



Yes, I'm running FreeBSD 8.0.




			
				wblock@ said:
			
		

> That find is not quite doing as intended.


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 /`



Output if following:


```
[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?


----------



## SirDice (Feb 14, 2012)

m4rtin said:
			
		

> Is it possible to detect this without documentation?


[cmd=]ls -li /rescue[/cmd]

Will show almost all files share the same inode, i.e. they are the same file.


----------



## wblock@ (Feb 14, 2012)

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.



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?



Yes.


----------



## m4rtin (Feb 24, 2012)

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


```
[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 ~]#
```


----------



## _martin (Feb 24, 2012)

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.


----------



## m4rtin (Feb 25, 2012)

wblock@ said:
			
		

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



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:
> 
> ...



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]


```
[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


----------



## _martin (Feb 25, 2012)

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.


----------



## m4rtin (Feb 26, 2012)

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).
> 
> ...



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:


```
lsof +L1 | sort -nk7
```

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


```
[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


----------



## _martin (Feb 27, 2012)

m4rtin said:
			
		

> However, how does *df* work? Does it analyze file-system metadata? :OOO



Look at /usr/src/bin/df/df.c for more details. It calls statfs(2) syscall to obtain filesystem statistics.


----------



## _martin (Feb 27, 2012)

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.



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`

```
/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`

```
/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.


----------

