Hallo,
root@-fw:/ # df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/rootfs 13G 8.2G 4.2G 66% /
devfs 1.0K 1.0K 0B 100% /dev
devfs 1.0K 1.0K 0B 100% /var/dhcpd/dev
devfs 1.0K 1.0K 0B 100% /var/unbound/dev
root@-fw:/ # df -H
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/rootfs 14G 8.8G 4.5G 66% /
devfs 1.0k 1.0k 0B 100% /dev
devfs 1.0k 1.0k 0B 100% /var/dhcpd/dev
devfs 1.0k 1.0k 0B 100% /var/unbound/devDementsprechend ist die Platte mit 8,8 GB oder 8.2 GB belegt. Warum die Unterschiede? Obwohl df nur mit einer anderen Option gestartet wurde. So jetzt will ich wissen mit was...
Quote
root@-fw:/ # du -h -d 1
4.0K ./.snap
4.9M ./bin
254M ./boot
158M ./conf
4.5K ./dev
2.9M ./etc
4.0K ./home
16M ./lib
192K ./libexec
4.0K ./media
4.0K ./proc
4.0K ./rescue
60K ./root
13M ./sbin
1.6G ./usr
145M ./var
2.6M ./tmp
4.0K ./mnt
4.0K ./net
1.3M ./lost+found
2.2G .
Hier sind also nur 2,1 GB belegt. Allerdings sind lauf df 8,8GB oder 8,2GB belegt. Hat jemand eine Idee/Erkärung woran das liegen könnte ...
Aus der df(1) manual page:
Quote-H "Human-readable" output. Use unit suffixes: Byte, Kilobyte, Megabyte, Gigabyte, Terabyte and Petabyte
in order to reduce the number of digits to three or less using base 10 for sizes.
-h "Human-readable" output. Use unit suffixes: Byte, Kilobyte, Megabyte, Gigabyte, Terabyte and Petabyte
in order to reduce the number of digits to three or less using base 2 for sizes.
Habe es mal markiert... Es wird nur anders gezählt. Der effektive Verbrauch ist aber gleich. ;)
Grüsse
Franco
Danke, aber das zweite Problem ist wesentlich Interessanter ...
Ein Mal werden die Dateien aufsummiert (du), das andere Mal die verbrauchten Inodes (df).
Grüsse
Franco
Danke Franko!.
Also bei Linux-Systemen ist du und df gleich, aber vielleicht ist ja bei FreeBSD es doch etwas anderes...
Wie haben mehrere OPNsens Systeme und auf einen anderen ist das Ergebniss von df und du gleich...
root@fw1:/ # du -h -d 1
4.0K ./.snap
4.9M ./bin
254M ./boot
5.6M ./conf
3.5K ./dev
2.6M ./etc
4.0K ./home
13M ./lib
192K ./libexec
4.0K ./media
4.0K ./proc
4.0K ./rescue
24K ./root
13M ./sbin
1.5G ./usr
64M ./var
2.6M ./tmp
4.0K ./mnt
4.0K ./net
44K ./lost+found
1.8G .
root@fw1:~ # df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ufs/OPNsense 14G 1.8G 11G 14% /
devfs 1.0K 1.0K 0B 100% /dev
devfs 1.0K 1.0K 0B 100% /var/dhcpd/dev
devfs 1.0K 1.0K 0B 100% /var/unbound/dev
Das spricht gegen die Inode-These, wie sieht es bei euch aus?
Kommt auf die Faktoren an: SD Karte oder Festplatte und welches Image verwendet wird.
Grüsse
Franco
Beide Geräte sind vom selben Hersteller. Es sind sogar fast die gleichen Platten drin:
Quoteroot@fw1:/ # geom disk list
Geom name: ada0
Providers:
1. Name: ada0
Mediasize: 16013942784 (15G)
Sectorsize: 512
Mode: r1w1e4
descr: SP016GIMSA305SV0
ident:
rotationrate: 0
fwsectors: 63
fwheads: 16
Quoteroot@-fw:/ # geom disk list
Geom name: ada0
Providers:
1. Name: ada0
Mediasize: 16013942784 (15G)
Sectorsize: 512
Mode: r1w1e3
descr: SP016GIMSA301SV0
ident:
rotationrate: 0
fwsectors: 63
fwheads: 16
Das eine System mit der korrekten Größenanzeige hat noch nie ein MajorUpgrade von OPNsense mit machen müssen, es ist erst ein paar Monate alt.
Das System mit der unkorrekten Größenangabe läuft schon seit 3 Jahren seit OPNsense 18.1 und hat einige Major-Upgrades mitgemacht..
Dann boote die Kiste mal mit angeschlossener Konsole im Single User Mode und mach ein fsck ...
ja an das neu booten mit fsck habe ich auch schon gedacht...
Allerdings kann man das bei einer produktiven FW nicht zu jeder Zeit machen ....
Also ein Neustart der OPNsense hat geholfen. Wahrscheinlich hat es bei Neustart automatisch ein fsck gemacht...
Den SingelUser Mode gab es beim Bootloader nicht ...
Danke an alle ..