Disk is 104% full
-
I have no idea what's /dev/ufsid/558d3d40eba9a34e - if you hacked pfSense to mount another disk completely outside of existing directory structure, you need to pick up the pieces.
-
I have no idea what's /dev/ufsid/558d3d40eba9a34e - if you hacked pfSense to mount another disk completely outside of existing directory structure, you need to pick up the pieces.
It's a reference to the disk containing the root file system using ufsid, which you can switch to using /usr/local/sbin/ufslabels.sh
The big advantage of this approach is that changes to controller names don't leave your system unbootable.
It's clear that the OP's high disk usage is in /var/db from the output posted, so the next step is du -hd1 /var/db
-
with du -hd1 /var/db the result is :
4.6M /var/db/rrd
616K /var/db/pbi
4.0K /var/db/portsnap
4.0K /var/db/ports
4.0K /var/db/pkg
4.0K /var/db/ipf
4.0K /var/db/hyperv
4.0K /var/db/freebsd-update
4.0K /var/db/entropy
4.0K /var/db/pingstatus
4.0K /var/db/pingmsstatus
4.0K /var/db/cpelements
11M /var/db/ntop
4.0K /var/db/squidGuard
17M /var/db -
I read your original output twice, came to the correct conclusion, then came to an incorrect conclusion and posted based on it. I mixed up M and G. /var is not the problem - it's only a few tens of megabytes. You're looking for something that uses gigabytes.
Try du -hd1 /
I have a suspicion that full backups in /root might be the problem. What does ls -l /root/*.tgz show?
-
Look. There's a GUI button to wipe Squid cache. Why on earth don't you use it?! Where did you place the Squid cache? How many disks you have on your pfSense box?
-
Where is that button? I can't find it. Squid is placed under /var/squid/cache. I have one disk.
-
It's very surprisingly located on the 'Local Cache' tab…
-
I don't have this button
-
Yeah, when you are using Squid 2.7, you don't and won't have any such button. Noone maintains that package. No good reason to use it either. Dead crap.
-
David_W is right. This doesn't look like a Squid cache problem. Run the command he suggests (du -hd1 /) and see what the output shows. You're looking for a folder somewhere containing gigs of data.
-
I run it;=. It displays :
4.0K /.snap
17M /boot
904K /bin
12K /conf.default
3.0K /dev
18M /etc
56K /home
14M /kernels
264K /libexec
7.9M /lib
405M /root
3.4M /sbin
31G /usr
50M /var
248K /tmp
4.0K /mnt
5.9M /cf
4.0K /media
4.0K /proc
4.0K /rescue
4.0K /scripts
4.0K /tank
184K /lost+found
32G / -
31G /usr
There's your problem. Run 'du -hd1 /usr' to see what subdirectory under there is taking up all the space and address the issue accordingly.
-
When I run it, the result is :
31G ./pbi
4.0K ./obj
460K ./libexec
16K ./lib32
38M ./share
30M ./lib
5.3M ./bin
5.5M ./sbin
155M ./local
31G . -
Keep going. So what folder under '/usr/pbi' is full? (Hint: run 'du -hd1 /usr/pbi'). My guess is that you have a load of Squidguard cache info sitting in there.
-
I run it :
12K ./etc
28K ./share
4.0K ./rc.d
16K ./bin
8.0K ./man
4.0K ./.hashdir
211M ./freeradius-i386
73M ./squid-i386
399M ./ntopng-i386
30G ./sarg-i386
41M ./bandwidthd-i386
31G .then I run du -hd1/sarg-i386/ and the result is :
30G ./local
4.0K ./rc.d
4.0K ./pbimeta
4.0K ./virtbase
4.0K ./linux
4.0K ./run
12K ./pbiconf
36K ./bin
30G .
then I run du -hd1/sarg-i386/local and the result is :
8.7M ./sbin
6.0M ./share
1.1M ./etc
2.2M ./include
14M ./lib
56K ./libdata
2.1M ./bin
816K ./info
30G ./sarg-reports
30G . -
Yeah. So, what's exactly your question? Delete the Sarg cruft. How on earth have you managed to accumulate 30 gigs of reports in 3 months? Are you running that nonsense every 5 minutes or WTF?
-
Thnaks to all. I deleted all the sarg reports and now I have a disk with 5% use.