Freeing up space on the disks
-
@stephenw10 When using the df -a command I get:
Filesystem 512-blocks Used Avail Capacity Mounted on /dev/ufsid/5edf741a475fe581 38557496 27083392 8389512 76% / devfs 2 2 0 100% /dev tmpfs 8192 2488 5704 30% /var/run tmpfs 8192 2920 5272 36% /var/run devfs 2 2 0 100% /var/dhcpd/dev -
Hmm, then why doesn't it show in
du -h -d1 /
I'll still bet it's in /var try:
du -h -d1 /var -
@stephenw10 When I run the "du -h -d1 /var" command I get this:
4.0K /var/msgs
1.3M /var/run
12K /var/audit
4.0K /var/backups
4.0K /var/preserve
4.0K /var/crash
4.0K /var/mail
4.0K /var/heimdal
4.0K /var/account
425M /var/db
241M /var/cache
4.0K /var/yp
32K /var/spool
4.0M /var/tmp
8.0K /var/cron
4.0K /var/rwho
4.0K /var/games
4.0K /var/authpf
3.2M /var/log
64K /var/unbound
12K /var/at
4.0K /var/empty
7.6M /var/etc
4.4M /var/dhcpd
8.0K /var/lib
687M /var -
Hmm, not there then. So there's ~10GB being used somewhere in that device that just isn't shown mounted filesystem...
Try
gpart listsee if that shows the expected values. -
@stephenw10 Here is the "gpart lis" output
Geom name: da0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 125829119
first: 63
entries: 4
scheme: MBR
Providers:- Name: da0s1
Mediasize: 21474803200 (20G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 32768
Mode: r2w2e5
efimedia: HD(1,MBR,0x90909090,0x40,0x27fffbf)
attrib: active
rawtype: 165
length: 21474803200
offset: 32768
type: freebsd
index: 1
end: 41943038
start: 64
Consumers: - Name: da0
Mediasize: 64424509440 (60G)
Sectorsize: 512
Mode: r2w2e7
Geom name: da0s1
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 41942974
first: 0
entries: 8
scheme: BSD
Providers:- Name: da0s1a
Mediasize: 20401094656 (19G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 32768
Mode: r1w1e2
rawtype: 7
length: 20401094656
offset: 0
type: freebsd-ufs
index: 1
end: 39845887
start: 0 - Name: da0s1b
Mediasize: 1073708032 (1.0G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 3221258240
Mode: r1w1e1
rawtype: 1
length: 1073708032
offset: 20401094656
type: freebsd-swap
index: 2
end: 41942973
start: 39845888
Consumers: - Name: da0s1
Mediasize: 21474803200 (20G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 32768
Mode: r2w2e5
- Name: da0s1
-
Hmm, is there some huge coredump file directly in the root of / that's somehow not being counted?
-
@stephenw10 hmm could be?
How do I check that or should I just peform a delete_coredump? -
I would just look in it manually:
ls -ls /Coredumps are usually in /root though so check there too:
ls -ls /root -
@stephenw10 ls -ls / gave me this:
total 65833 8 drwx------ 2 root wheel 512 Aug 25 2020 .cache 8 -rw-r--r-- 2 root wheel 1023 Jan 31 2022 .cshrc 8 -rw-r--r-- 2 root wheel 1067 Oct 18 2022 .profile 8 drwxrwxr-x 2 root operator 512 Jun 9 2020 .snap 65600 -r-------- 1 root wheel 33554432 Jun 9 2020 .sujournal 16 -r--r--r-- 1 root wheel 6121 Jan 31 2022 COPYRIGHT 8 drwxr-xr-x 2 root wheel 1024 Oct 18 2022 bin 8 drwxr-xr-x 11 root wheel 1536 Oct 18 2022 boot 8 drwxr-xr-x 3 root wheel 512 Jan 31 2022 cf 0 lrwxr-xr-x 1 root wheel 8 Mar 24 2020 conf -> /cf/conf 8 drwxr-xr-x 2 root wheel 512 Jan 31 2022 conf.default 1 dr-xr-xr-x 12 root wheel 512 Oct 18 2022 dev 8 -rw------- 1 root wheel 4096 Jun 9 2020 entropy 16 drwxr-xr-x 28 root wheel 4608 Jun 22 23:38 etc 8 drwxr-xr-x 17 root wheel 512 Jun 22 23:38 home 8 drwxr-xr-x 5 root wheel 1536 Oct 18 2022 lib 8 drwxr-xr-x 3 root wheel 512 Oct 18 2022 libexec 8 drwxr-xr-x 2 root wheel 512 Mar 24 2020 media 8 drwxr-xr-x 2 root wheel 512 Mar 24 2020 mnt 8 drwxr-xr-x 2 root wheel 512 Jan 31 2022 net 8 dr-xr-xr-x 2 root wheel 512 Mar 24 2020 proc 8 drwxr-xr-x 2 root wheel 2560 Oct 18 2022 rescue 8 drwxr-xr-x 4 root wheel 512 Jun 2 09:48 root 8 drwxr-xr-x 2 root wheel 2560 Oct 18 2022 sbin 0 lrwxr-xr-x 1 root wheel 11 Mar 24 2020 sys -> usr/src/sys 32 drwxrwxrwt 7 root wheel 15360 Jun 26 15:38 tmp 8 drwxr-xr-x 13 root wheel 512 Jan 31 2022 usr 8 drwxr-xr-x 27 root wheel 512 Jan 31 2022 var -
@stephenw10 And the ls -ls /root gave me this:
total 781128 8 drwx------ 3 root wheel 512 Oct 18 2022 .cache 8 -rw-r--r-- 2 root wheel 1023 Jan 31 2022 .cshrc 0 -rw-r--r-- 1 root wheel 0 Oct 18 2022 .hushlogin 8 -rw-r--r-- 1 root wheel 80 Jan 31 2022 .k5login 8 -rw-r--r-- 1 root wheel 328 Jan 31 2022 .login 8 -rw-r--r-- 2 root wheel 1067 Oct 18 2022 .profile 8 -rw------- 1 root wheel 1024 Jun 21 13:52 .rnd 8 -rw-r--r-- 1 root wheel 1943 Oct 18 2022 .shrc 8 -rw-r--r-- 1 root wheel 3090 Oct 18 2022 .tcshrc 68992 -rw------- 1 root wheel 35291136 Sep 4 2020 charon.core 8 -r-xr-xr-x 1 root wheel 1124 Dec 19 2022 disconnect.sh 544832 -rw------- 1 root wheel 278818816 Jul 22 2020 ntopng.core 56 -rw-r--r-- 1 root wheel 24614 Jun 2 09:50 packetcapture.cap 0 -rw-r--r-- 1 root wheel 0 Jun 2 09:47 packetcapture.start 167168 -rw------- 1 root wheel 85536768 Oct 19 2022 php-cgi.core 8 drwxr-xr-x 2 root wheel 512 Aug 18 2020 scriptsSeems like the .core files are bigger?
-
Yes, but still only 100s of MBs not GBs. You can remove those core files though.
-
@stephenw10 Weird. I don't understand where 10GB would lie undetected.
How do I remove .core from root?
-
Indeed, I'm not sure here that space is being used.
You can remove those files from the command line as root or at Diag > Command Prompt like:
rm /root/ntopng.core
Obviously be careful doing that!Steve
-
@stephenw10 Got 2% less... (77 to 75%)
Dont really know what to do more then the things you suggested.There must be something that stores those 10GB's..
