Toon posts:

[debian] 'df' negatief?

Pagina: 1
Acties:

Verwijderd

Topicstarter
Hoe is dit:

$ df

code:
1
2
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda2            -802259910193         1         0  34% /


in vredesnaam mogelijk?

Het is (denk ik) gebeurd na de installatie van firefox (+ benodigde libs etc.),
toen heeft 'ie (mbv apt-get) een hele hoop bestanden ge-update.
Maar een negatieve /dev/hda2 ??? :? :?

Stukje van /var/log/messages:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
Jul 13 23:01:10 yozd kernel: eepro100_detach(eth0) c5b66000
Jul 13 23:01:11 yozd kernel: cs: cb_free(bus 1)
Jul 13 23:01:11 yozd kernel: unloading PCMCIA Card Services
Jul 13 23:01:15 yozd kernel: Kernel logging (proc) stopped.
Jul 13 23:01:15 yozd kernel: Kernel log daemon terminating.
Jul 13 23:01:15 yozd exiting on signal 15
Jul 13 23:03:40 yozd syslogd 1.4.1#10: restart.
Jul 13 23:03:40 yozd kernel: klogd 1.4.1#10, log source = /proc/kmsg started.
Jul 13 23:03:40 yozd kernel: Inspecting /boot/System.map-2.2.20-idepci
Jul 13 23:03:41 yozd kernel: Loaded 8033 symbols from
/boot/System.map-2.2.20-idepci.
Jul 13 23:03:41 yozd kernel: Symbols match kernel version 2.2.20.
Jul 13 23:03:41 yozd kernel: Loaded 7 symbols from 1 module.
Jul 13 23:03:41 yozd kernel: Linux version 2.2.20-idepci (herbert@gondolin) (gcc
version 2.7.2.3) #1 Sat Apr 20 12:45:19 EST 2002
Jul 13 23:03:41 yozd kernel: BIOS-provided physical RAM map:
Jul 13 23:03:41 yozd kernel:  BIOS-e801: 0009f000 @ 00000000 (usable)
Jul 13 23:03:41 yozd kernel:  BIOS-e801: 05f00000 @ 00100000 (usable)
Jul 13 23:03:41 yozd kernel: Detected 233867 kHz processor.
Jul 13 23:03:41 yozd kernel: Console: colour VGA+ 80x25
Jul 13 23:03:41 yozd kernel: Calibrating delay loop... 465.30 BogoMIPS
Jul 13 23:03:41 yozd kernel: Memory: 95432k/98304k available (1164k kernel code,
412k reserved, 1224k data, 72k init)
Jul 13 23:03:41 yozd kernel: Dentry hash table entries: 16384 (order 5, 128k)
Jul 13 23:03:41 yozd kernel: Buffer cache hash table entries: 131072 (order 7,
512k)
Jul 13 23:03:41 yozd kernel: Page cache hash table entries: 32768 (order 5,
128k)
Jul 13 23:03:41 yozd kernel: CPU: Intel Mobile Pentium MMX stepping 01
Jul 13 23:03:41 yozd kernel: Checking 386/387 coupling... OK, FPU using
exception 16 error reporting.
Jul 13 23:03:41 yozd kernel: Checking 'hlt' instruction... OK.
Jul 13 23:03:41 yozd kernel: Checking for popad bug... OK.
Jul 13 23:03:41 yozd kernel: Intel Pentium with F0 0F bug - workaround enabled.
Jul 13 23:03:41 yozd kernel: POSIX conformance testing by UNIFIX
Jul 13 23:03:41 yozd kernel: PCI: PCI BIOS revision 2.10 entry at 0xf73c3
Jul 13 23:03:41 yozd kernel: PCI: Using configuration type 1
Jul 13 23:03:41 yozd kernel: PCI: Probing PCI hardware
Jul 13 23:03:41 yozd kernel: Linux NET4.0 for Linux 2.2
Jul 13 23:03:41 yozd kernel: Based upon Swansea University Computer Society
NET3.039
Jul 13 23:03:41 yozd kernel: NET4: Unix domain sockets 1.0 for Linux NET4.0.
Jul 13 23:03:41 yozd kernel: NET4: Linux TCP/IP 1.0 for NET4.0
Jul 13 23:03:41 yozd kernel: IP Protocols: ICMP, UDP, TCP
Jul 13 23:03:41 yozd kernel: TCP: Hash tables configured (ehash 131072 bhash
65536)
Jul 13 23:03:41 yozd kernel: Starting kswapd v 1.5 
Jul 13 23:03:41 yozd kernel: vga16fb: initializing
Jul 13 23:03:41 yozd kernel: vga16fb: mapped to 0xc00a0000
Jul 13 23:03:41 yozd kernel: Console: switching to colour frame buffer device
80x30
Jul 13 23:03:41 yozd kernel: fb0: VGA16 VGA frame buffer device
Jul 13 23:03:41 yozd kernel: Serial driver version 4.27 with HUB-6 MANY_PORTS
MULTIPORT SHARE_IRQ enabled
Jul 13 23:03:41 yozd kernel: ttyS00 at 0x03f8 (irq = 4) is a 16550A
Jul 13 23:03:41 yozd kernel: ttyS02 at 0x03e8 (irq = 4) is a 16550A
Jul 13 23:03:41 yozd kernel: pty: 256 Unix98 ptys configured
Jul 13 23:03:41 yozd kernel: RAM disk driver initialized:  16 RAM disks of 4096K
size
Jul 13 23:03:41 yozd kernel: loop: registered device at major 7
Jul 13 23:03:41 yozd kernel: OPTI621X: IDE controller on PCI bus 00 dev a0
Jul 13 23:03:41 yozd kernel: OPTI621X: not 100%% native mode: will probe irqs
later
Jul 13 23:03:41 yozd kernel:     ide0: BM-DMA at 0x1000-0x1007, BIOS settings:
hda:pio, hdb:pio
Jul 13 23:03:41 yozd kernel: hda: IBM-DTCA-23240, ATA DISK drive
Jul 13 23:03:41 yozd kernel: hdb: UJDA120, ATAPI CDROM drive
Jul 13 23:03:41 yozd kernel: ide2: ports already in use, skipping probe
Jul 13 23:03:41 yozd kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Jul 13 23:03:41 yozd kernel: hda: IBM-DTCA-23240, 3102MB w/468kB Cache,
CHS=788/128/63
Jul 13 23:03:41 yozd kernel: hdb: ATAPI 16X CD-ROM drive, 128kB Cache
Jul 13 23:03:41 yozd kernel: Uniform CD-ROM driver Revision: 3.11
Jul 13 23:03:41 yozd kernel: Floppy drive(s): fd0 is 1.44M
Jul 13 23:03:41 yozd kernel: FDC 0 is a post-1991 82077
Jul 13 23:03:41 yozd kernel: 3c59x.c 18Feb01 Donald Becker and others
http://www.scyld.com/network/vortex.html
Jul 13 23:03:41 yozd kernel: pcnet32.c: PCI bios is present, checking for
devices...
Jul 13 23:03:41 yozd kernel: via-rhine.c:v1.08b-LK1.0.1 12/14/2000  Written by
Donald Becker
Jul 13 23:03:41 yozd kernel:   http://www.scyld.com/network/via-rhine.html
Jul 13 23:03:41 yozd kernel: Partition check:
Jul 13 23:03:41 yozd kernel:  hda: hda1 hda2
Jul 13 23:03:41 yozd kernel: apm: BIOS version 1.2 Flags 0x03 (Driver version
1.13)
Jul 13 23:03:41 yozd kernel: apm: disabled on user request.
Jul 13 23:03:41 yozd kernel: VFS: Mounted root (ext2 filesystem) readonly.
Jul 13 23:03:41 yozd kernel: Freeing unused kernel memory: 72k freed
Jul 13 23:03:41 yozd kernel: Adding Swap: 64476k swap-space (priority -1)
Jul 13 23:03:43 yozd kernel: Linux PCMCIA Card Services 3.1.33
Jul 13 23:03:43 yozd kernel:   kernel build: 2.2.20-idepci #1 Sat Apr 20
12:45:19 EST 2002
Jul 13 23:03:43 yozd kernel:   options:  [pci] [cardbus] [apm]
Jul 13 23:03:43 yozd kernel: PCI routing table version 1.0 at 0xf5c00
Jul 13 23:03:43 yozd kernel:   00:11.0 -> irq 15
Jul 13 23:03:43 yozd kernel:   00:11.1 -> irq 11
Jul 13 23:03:43 yozd kernel: Intel ISA/PCI/CardBus PCIC probe:
Jul 13 23:03:43 yozd kernel:   TI 1131 rev 01 PCI-to-CardBus at slot 00:11, mem
0x7fffe000
Jul 13 23:03:43 yozd kernel:     host opts [0]: [ring] [pci + serial irq] [pci
irq 15] [lat 66/176] [bus 1/1]
Jul 13 23:03:43 yozd kernel:     host opts [1]: [ring] [pci + serial irq] [pci
irq 11] [lat 66/176] [bus 2/2]
Jul 13 23:03:43 yozd kernel:     ISA irqs (scanned) = 3,4,5,7,9,10 PCI status
changes
Jul 13 23:03:44 yozd kernel: cs: cb_alloc(bus 1): vendor 0x8086, device 0x1229
Jul 13 23:03:45 yozd kernel: eepro100.c:v1.09t 9/29/99 Donald Becker
http://www.scyld.com/network/eepro100.html
Jul 13 23:03:46 yozd xfs: ignoring font path element
/usr/lib/X11/fonts/cyrillic/ (unreadable) 
Jul 13 23:03:46 yozd kernel: cs: cb_config(bus 1)
Jul 13 23:03:46 yozd kernel: cs: IO port probe 0x0100-0x04ff: excluding
0x100-0x107 0x220-0x22f 0x250-0x257 0x330-0x337 0x378-0x37f 0x388-0x38f
0x408-0x40f 0x480-0x48f 0x4d0-0x4d7
Jul 13 23:03:46 yozd kernel: cs: IO port probe 0x0a00-0x0aff: clean.
Jul 13 23:03:46 yozd kernel: cs: IO port probe 0x0c00-0x0cff: excluding
0xcf8-0xcff
Jul 13 23:03:46 yozd kernel:   fn 0 bar 1: mem 0x60060000-0x60060fff
Jul 13 23:03:46 yozd kernel:   fn 0 bar 2: io 0x140-0x17f
Jul 13 23:03:46 yozd kernel:   fn 0 bar 3: mem 0x60040000-0x6005ffff
Jul 13 23:03:46 yozd kernel:   irq 15
Jul 13 23:03:46 yozd kernel: eepro100_attach(bus 1, function 0)
Jul 13 23:03:46 yozd kernel: eth0: Intel PCI EtherExpress Pro100 at 0xc682b000,
00:03:47:18:B2:01, IRQ 15.
Jul 13 23:03:46 yozd kernel:   Board assembly 730155-001, Physical connectors
present: RJ45
Jul 13 23:03:46 yozd kernel:   Primary interface chip i82555 PHY #1.
Jul 13 23:03:46 yozd kernel:   General self-test: passed.
Jul 13 23:03:46 yozd kernel:   Serial sub-system self-test: passed.
Jul 13 23:03:46 yozd kernel:   Internal registers self-test: passed.
Jul 13 23:03:46 yozd kernel:   ROM checksum self-test: passed (0xdbd8681d).
Jul 13 23:03:46 yozd kernel:   Receiver lock-up workaround activated.
Jul 13 23:03:46 yozd xfs: ignoring font path element /usr/lib/X11/fonts/CID

Verwijderd

Topicstarter
ik heb via Google 1 post gevonden van iemand in een nieuwsgroep die dit
schreef:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Yes, this is an intended feature of the ext2fs.

The ext2fs allows you to reserve space for use only by root.  This
prevents critical system programs from running out of space if users
have exhausted all of the unreserved space, and also helps to minimise
disk fragmentation.  You can determine the reserved space during
mke2fs - use "mke2fs -m 0" if you don't want any.

Anyway, if you are logged on as root, you can fill up this reserved
space.

The system is designed to report disk useages as percentages of the
*unreserved* space; so "100% full" means that the reserved space limit
has been reached.  Once this reserved space itself fills up, the
percentage used will exceed 100%, and the free space will become
negative.

This is quite normal behaviour, and incidentally is also the way that
the BSD ffs works - so it's not just a Linux quirk.


Ik kan dit verhaal echter nergens bevestigd krijgen... :/

Ook hebben mensen het erover dat dit kan voorkomen bij een te grote HD.
Die van mij is 3 GB, dus dat kan het iig niet zijn :) .

[ Voor 8% gewijzigd door Verwijderd op 14-07-2004 01:26 ]


  • arikkert
  • Registratie: Juli 2002
  • Laatst online: 17-02 12:23
wat maak fsck ervan ?
tis de rootpartitie, misschien moet je dan een keer van andere disk booten.

  • The Jester
  • Registratie: Januari 2000
  • Laatst online: 26-11-2024

The Jester

The fool escaped from paradise

Ext2 en Ext3 resserveren altijd 5% voor root.

Wat krijg je als je df -h doet ?
Dan hoort 'ie namelijk 'hunam readable format' weer te geven (MB's en GB's) ipv blocks.
Wellicht is het een aardig idee om de partitie om te zetten naar ext3.
Dat kan met tune2fs -j. Dan heb je in ieder geval een journallig FS, hetgeen het wat gemakkelijker maakt om fouten op te sporen.

As you grow up and leave the playground where you kissed your prince and found your frog...


  • RvdH
  • Registratie: Juni 1999
  • Laatst online: 14:54

RvdH

Uitvinder van RickRAID

Misschien is je /etc/mtab kaduuk?

Verwijderd

Topicstarter
arikkert schreef op 14 juli 2004 @ 08:05:
wat maak fsck ervan ?
tis de rootpartitie, misschien moet je dan een keer van andere disk booten.
fsck zegt:

code:
1
2
3
fsck 1.27 (8-Mar-2002)
e2fsck 1.27 (8-Mar-2002)
/dev/hda2: clean, 61441/389376 files, 253218/778176 blocks
The_Jester schreef op 14 juli 2004 @ 10:15:
Wat krijg je als je df -h doet ?
Dan hoort 'ie namelijk 'hunam readable format' weer te geven (MB's en GB's) ipv blocks.
df -h geeft:

code:
1
2
Filesystem        Size    Used      Avail  Use%  Mounted on
/dev/hda2       -8022559910193k   1k   0.0k     /


Hetzelfde als 'df'...
RickJansen schreef op 14 juli 2004 @ 10:29:
Misschien is je /etc/mtab kaduuk?
cat /etc/mtab:

code:
1
2
/dev/hda2 / ext2 rw,errors=remount-ro 0 0
proc /proc proc rw 0 0


Echt vreemd, want alles werkt wel gewoon... :?

Verwijderd

Hmmmm, ik kan me herinneren dat ik dit ook een paar keer gehad heb. Ik heb me er alleen nooit zoveel van aangetrokken aangezien de meeste van mijn systemen niet langer dan 2 weken op de harde schijf staan :P
Anyway, ik ben er nooit achteraan geweest, maar aangezien ik ook Debian gebruik en dit probleem ook wel eens gehad heb ben ik wel benieuwd hoe dit afloopt. :)

  • RvdH
  • Registratie: Juni 1999
  • Laatst online: 14:54

RvdH

Uitvinder van RickRAID

Hmm. umount je /proc eens, en remount hem dan weer (mount -a proc)?

  • Paul
  • Registratie: September 2000
  • Laatst online: 17:00
Ik heb het laatst ook gehad :)

Laat me raden, die schijf / partitie is (zo goed als) leeg? Het zit hem inderdaad in de ruimte die voor root gereserveerd is.

Toen ik op mijn schijf (van 916gb) een bestand aanmaakte van 1gb was het over :)

dd if=/dev/zero of=./blaat bs=1M count=1024

Ik heb de reserved blocks van 5 naar naar 1% gezet (kost me nog altijd bijna 10gb :( maar helemaal uitzetten was ook niet verstandig volgens een aantal bronnen, daarnaast heb ik sparse_super aangezet) maar ik hoefde iig niet de hele 10gb vol te zetten voordat df weer normaal werkte.

"Your life is yours alone. Rise up and live it." - Richard Rahl
Rhàshan - Aditu Sunlock


Verwijderd

Topicstarter
Paul Nieuwkamp schreef op 14 juli 2004 @ 13:54:
Ik heb het laatst ook gehad :)

Laat me raden, die schijf / partitie is (zo goed als) leeg? Het zit hem inderdaad in de ruimte die voor root gereserveerd is.
Mijn schijf is niet zo goed als leeg...
Hij is maar 3 GB groot en ik heb er een "normale" Debian installatie op gezet
(incl. X + Enlightenment en Firefox etc.). Volgens mij klopt die 34% in use namelijk
wel gewoon...
RickJansen schreef op 14 juli 2004 @ 13:44:
Hmm. umount je /proc eens, en remount hem dan weer (mount -a proc)?
Heeft geen effect gehad..

:?

  • RvdH
  • Registratie: Juni 1999
  • Laatst online: 14:54

RvdH

Uitvinder van RickRAID

En als je reboot blijft het?

Verwijderd

Topicstarter
RickJansen schreef op 14 juli 2004 @ 16:16:
En als je reboot blijft het?
Yup.

Ik bedenk met net trouwens dat deze laptop toen ik hem kreeg van mijn pa
(laptop was afgeschreven voor het bedrijf waar die werkte) het gelijk al niet
deed. Hij is toen teruggestuurd naar het bedrijf en de systeembeheerder daaro
zei dat de HD los zat. Hij zou hem hebben vastgedraaid en ik kreeg hem weer
terug. Toen heb ik een jaartje XP erop gedraaid en verder nooit problemen
ofzo gehad.

Nu heb ik er voor het eerst linux (debian) op staan en krijg ik deze "error".
(alhoewel ook weer niet meteen, hij heeft 2/3 dagen gewoon de normale inhoud
van de HD aangegeven).

Maar zou het kunnen dat de HD gewoon kapot is? fsck gaf verder niks vreemds aan
en alles werkt ook nog gewoon normaal, dus zo heel druk maak ik me ook niet,
maar het blijft wel vreemd.

[ Voor 2% gewijzigd door Verwijderd op 14-07-2004 17:48 . Reden: typo ]


Verwijderd

Kan het zijn dat er op die partitie een relatief groot aantal reserved blocks zijn en dat df dus correcterwijze een negatief getal laat zien?

Kijk eens of cat /proc/partitions ook een negatief getal geeft? Zo nee, als je het percentage reserved blocks met tune2fs -m 1 /dev/hda2 op 1% zet, heb je dan nog negatieve waardes met df?

Verwijderd

Topicstarter
Verwijderd schreef op 14 juli 2004 @ 21:38:
Kan het zijn dat er op die partitie een relatief groot aantal reserved blocks zijn en dat df dus correcterwijze een negatief getal laat zien?

Kijk eens of cat /proc/partitions ook een negatief getal geeft? Zo nee, als je het percentage reserved blocks met tune2fs -m 1 /dev/hda2 op 1% zet, heb je dan nog negatieve waardes met df?
$ cat /etc/partitions
code:
1
2
3
4
5
6
major minor  #blocks  name

   3     0    3177216 hda
   3     1      64480 hda1
   3     2    3112704 hda2
   3    64     600268 hdb


Na het 'tune2fs' commando is de output van 'df' nog steeds hetzelfde...

[ Voor 4% gewijzigd door Verwijderd op 14-07-2004 23:43 . Reden: typo ]


Verwijderd

Topicstarter
*kickje* O-)

Ik heb overigens net ff wat packages ge-upgrade (met apt-get upgrade) en
zelfs 'df' gedelete (d.m.v. apt-get remove fileutils) en daarna weer geinstalleerd
door remove te vervangen door install, maar het probleem blijft.

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 11:03

deadinspace

The what goes where now?

Een aantal mensen hebben opgemerkt dat ext2/3 root-reserved space (kunnen) hebben. Dat is ook zo, maar dat is hier niet het probleem :)
Verwijderd schreef op 13 juli 2004 @ 23:17:
code:
1
2
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda2            -802259910193         1         0  34% /
1) Het fs is maar 34% vol, niet > 95%
2) Is 802259910193 blocks (oftewel: 7500 terabyte) niet wat veel?

Dus (zeker gezien dat veel te grote getal) is een beschadigd fs het meest voor de hand liggend.
Verwijderd schreef op 14 juli 2004 @ 12:21:
code:
1
2
3
fsck 1.27 (8-Mar-2002)
e2fsck 1.27 (8-Mar-2002)
/dev/hda2: clean, 61441/389376 files, 253218/778176 blocks
Als een filesystem gemarkeerd is als 'clean', en dat is het onder normale omstandigheden, dan doet fsck niks. Gebruik fsck -f <device> om te fscken ook al is het filesytem clean.

Verwijderd

Topicstarter
deadinspace schreef op 16 juli 2004 @ 02:00:

Als een filesystem gemarkeerd is als 'clean', en dat is het onder normale omstandigheden, dan doet fsck niks. Gebruik fsck -f <device> om te fscken ook al is het filesytem clean.
Ik heb al eens "ext2fsck -f /dev/hda2" (oid) uitgevoerd en toen kreeg ik 1 error:

special (device/socket/fifo) node 358508 has non-zero size. (fix?)

Toen koos ik natuurlijk voor 'yes'.

Nu runde ik net 'fsck -f /dev/hda2' en nu krijg ik dezelfde error... weer gefixed en
nu run ik 'fsck -f /bla' voor de 3e keer en nu krijg ik geen errors (die non-zero
error was overigens ook de enige error die ik uberhaupt kreeg).

Maar: het probleem is nog steeds niet verholpen. Ik begin het echt vaag te vinden,
ben toch niet de enige die dit kan hebben? Op de debian-user mailinglist weten
ze het ook niet :) .

PS
Er zijn wel meerdere mensen waarbij 'df' een negatieve waarde aangeeft, maar
bij iedereen staat USE% ook op boven de 100..die van mij staat echter keurig op
30-35%...

Verwijderd

Topicstarter
Ik denk dat het probleem verholpen is.
Op een ander forum kwam iemand met de opmerking dat waarschijnlijk glibc is
geupdate, omdat "firefox" (wat ik geinstalleerd heb) uit de "testing" (sarge)
distro komt en daar dus ook de libs vandaan heeft gehaald.

Ik ga nu mijn hele systeem upgraden (stable in sources.list vervangen door 'sarge')
en dat zou de oplossing kunnen zijn... ben benieuwd :) .

- edit -

Ik heb net alleen 'fileutils' geupdate (vanuit de testing, sarge, distro ge-apt-get dus,
en 'df' geeft weer de normale output! Het werkt dus! :)

[ Voor 21% gewijzigd door Verwijderd op 16-07-2004 12:01 . Reden: update ]


  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 11:03

deadinspace

The what goes where now?

Hmm, dat zou kunnen ja. Het is goed mogelijk dat de Sarge libc wat van dergelijke dingen verhuisd heeft naar 64 bit integers, om met grotere filesystems om te kunnen gaan, en dat de Woody fileutils dat niet verwachten.

Nouja, fijn dat het opgelost is iig :)
Pagina: 1