Re: a monster stole my /
On Tue, 29 Apr 2008 14:40:09 +1000 Hartleigh Burton [EMAIL PROTECTED] wrote: Hiya! I have a problem with / currently being at 108% capacity. I have found a previous thread in the archives which explains a few questions but I can't find what is taking up all the additional space. At best without destroying what I still do not understand I can manage to get / to about 101% capacity. To answer a couple of potential questions straight up, there is nothing in /root and /tmp is on a separate partition. intranet# df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/da0s1a 989M986M-76M 108%/ devfs1.0K1.0K 0B 100%/dev /dev/da0s1e 989M216K910M 0%/tmp /dev/da0s1f 58G4.8G 48G 9%/usr /dev/da0s1d 4.8G2.2G2.3G49%/var /dev/da1p1 3.3T682G2.4T22%/db devfs1.0K1.0K 0B 100%/var/named/dev intranet# du -h -d1 2.0K ./.snap 1.5K ./dev 218K ./tmp 4.8G ./usr 2.2G ./var 1.7M ./etc 2.0K ./cdrom 2.0K ./dist 1.1M ./bin 71M ./boot 4.4M ./lib 360K ./libexec 2.0K ./media 512B ./net 2.0K ./proc 3.8M ./rescue 26K ./root 4.1M ./sbin 512B ./host 682G ./db 689G . If I move the old kernel/GENERIC files from /boot I can manage to get back to 101%, I really have no idea where the rest of the space has gone though. Is there any way to locate large files on a specific partition? I did have a problem not too long ago where my /db array did not mount and MySQL managed to recreate the default/sample database on /db/ mysql, could this default database be somewhere else on / while the / db array problem was fixed? *scratches head* It is possible that you have mounted a filesystem onto a non empty directory. The stuff in the dir used as a mount point will be hidden by the mount. Colin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
freebsd6.2-stable + ipfilter + policy routing mbuf leak
Hi all, I have a server running 6.2-stable that experiences mbuf leakage if I perform policy routing with ipfilter. This is independent of the hardware as I have moved the disk to a different machine with different MB, NICs etc and had the same result. The server is running quagga, postfix and ipfilter for some basic firewalling. The policy routing was to route outgoing web traffic to a second internet link. I have been running the same setup for several years on a 4.11 machine without any problems. Can anyone confirm this problem? Cheers, Colin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
routed corrupting arp table with multiple ip aliases ?
Hi all, I stumbled on this while trying to track down an mbuf leak on a new server. It seems that routed corrupts the arp table on FreeBSD 6.2 when there are more than one ip alias on an interface. The behaviour differs depending on whether routed is enable in rc.d or manually started after boot. How to repeat: configure multiple aliases on an interface if routed is not enabled in rc.d ping all aliases arp -a shows that each alias has the nics mac eg lnat.ips.gov.au (192.168.1.100) at 00:30:1b:ba:bb:01 on bge0 [permanent] knat.ips.gov.au (192.168.1.101) at 00:30:1b:ba:bb:01 on bge0 [permanent] run routed and wait a few seconds run arp -a again, the mac address for all aliases (except the last) will have changed to a 0 or 128 hex numbers seperated by :'s eg lnat.ips.gov.au (192.168.1.100) at 0 [permanent] knat.ips.gov.au (192.168.1.101) at 00:30:1b:ba:bb:01 on bge0 [permanent] All aliases are still pingable A netstat -r shows something like the following for the aliases 192.168.1.100 192.168.1.100 UHLW1 30 lo0 = 192.168.1.100/32 link#1 UC 0 0 bge0 192.168.1.101 00:30:1b:ba:bb:01 UHLW 1 16 lo0 = 192.168.1.101/32 link#1 UC 0 0 bge0 If routed is enabled in rc.d and the system rebooted only the last alias shows with arp -a . A netstat -r shows something like the following for the aliases 192.168.1.100 192.168.1.100 UH 1 30 bge0 = 192.168.1.100/32 link#1 UC 0 0 bge0 192.168.1.101 00:30:1b:ba:bb:01 UHLW 1 16 lo0 = 192.168.1.101/32 link#1 UC 0 0 bge0 Only the primary ip and the last alias are pingable. I have tried this on several machines running 6.2- stable with similar results. Can anyone confirm this behaviour. Cheers Colin -- -- Colin Yuile ([EMAIL PROTECTED]) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]