From nobody@FreeBSD.ORG  Wed May 10 08:18:19 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 96CEB37B623; Wed, 10 May 2000 08:18:19 -0700 (PDT)
Message-Id: <20000510151819.96CEB37B623@hub.freebsd.org>
Date: Wed, 10 May 2000 08:18:19 -0700 (PDT)
From: boxiao63@hotmail.com
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: Dont let filesys go over 4G if not supported
X-Send-Pr-Version: www-1.0

>Number:         18485
>Category:       bin
>Synopsis:       Dont let filesys go over 4G if not supported
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed May 10 08:20:00 PDT 2000
>Closed-Date:    Wed May 10 08:34:50 PDT 2000
>Last-Modified:  Tue Jun  6 12:00:03 PDT 2000
>Originator:     Bo
>Release:        3.4
>Organization:
>Environment:
FreeBSD cresendo.cisco.com 3.4-RELEASE FreeBSD 3.4-RELEASE #0: Fri Apr  7 14:55:47 PDT 2000     root@:/usr/src/sys/compile/CRESENDO3.4  i386

>Description:
Since 32 bit couter only go as high as 4.2G, no filesys over
that size should be allowed. With today's disk size, users
will attempt to do just that. Either labeling or newfs should
catch it. 

Many unexpected/unpredictable error happen when using the fs
portion beyond a 32 bit counter can count.
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: peter 
State-Changed-When: Wed May 10 08:34:50 PDT 2000 
State-Changed-Why:  
This is a bogus report.  We do support filesystems over 4G because 
we use 64 bit off_t's etc. 

From: David Greenman <dg@root.com>
To: boxiao63@hotmail.com
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/18485: Dont let filesys go over 4G if not supported 
Date: Wed, 10 May 2000 12:36:39 -0700

 >>Description:
 >Since 32 bit couter only go as high as 4.2G, no filesys over
 >that size should be allowed. With today's disk size, users
 >will attempt to do just that. Either labeling or newfs should
 >catch it. 
 >
 >Many unexpected/unpredictable error happen when using the fs
 >portion beyond a 32 bit counter can count.
 
    There are many production filesystems that are much much larger than that
 and have no problems. Can you be more specific about the trouble you are
 having? FreeBSD uses 64bit ints to store things that can be larger than
 32bits.
 
 -DG
 
 David Greenman
 Co-founder, The FreeBSD Project - http://www.freebsd.org
 Creator of high-performance Internet servers - http://www.terasolutions.com
 Pave the road of life with opportunities.
 

From: "Bo Xiao" <boxiao63@hotmail.com>
To: dg@root.com
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/18485: Dont let filesys go over 4G if not supported
Date: Tue, 06 Jun 2000 10:45:25 PDT

 What I saw was *many* crashes that I couldnt find the source.
 They happened when I did ls, save files under netscape, etc.
 The lost+found contained THOUSANDs of special files with sizes
 of 20 digit number, unknown users etc. When I tried to remove
 them as root, it crashed again. Fsck cant finish the check. Quit
 after many many errors(I used -y option). I ended up mounting
 the fs manually and backing up as many files as I could, followed
 by a newfs.
 
 I restricted my fs to under 4G. I still had to do newfs once.
 This time nothing in lost+found. fsck still cant do the job.
 
 I am using a Celeron 400. dmesg follows. Only thing I can think
 of is that I was also using a win98 with large partition(>2,8G)
 enabled. The two seem to disturb each other. I turned that off
 now. Could it be a msdos filesystem support issue?
 
 % dmesg
 Copyright (c) 1992-1999 FreeBSD Inc.
 Copyright (c) 1982, 1986, 1989, 1991, 1993
         The Regents of the University of California. All rights reserved.
 FreeBSD 3.4-RELEASE #0: Mon May 15 09:11:24 PDT 2000
     root@:/usr/src/sys/compile/CRESENDO3.4
 Timecounter "i8254"  frequency 1193182 Hz
 Timecounter "TSC"  frequency 397331442 Hz
 CPU: Pentium II/Xeon/Celeron (397.33-MHz 686-class CPU)
   Origin = "GenuineIntel"  Id = 0x652  Stepping = 2
   
 Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR>
 real memory  = 67108864 (65536K bytes)
 avail memory = 62541824 (61076K bytes)
 Preloaded elf kernel "kernel" at 0xc029f000.
 Pentium Pro MTRR support enabled
 Probing for devices on PCI bus 0:
 chip0: <Intel 82443BX host to PCI bridge> rev 0x03 on pci0.0.0
 chip1: <Intel 82443BX host to AGP bridge> rev 0x03 on pci0.1.0
 chip2: <Intel 82371AB PCI to ISA bridge> rev 0x02 on pci0.4.0
 ide_pci0: <Intel PIIX4 Bus-master IDE controller> rev 0x01 on pci0.4.1
 chip3: <Intel 82371AB Power management controller> rev 0x02 on pci0.4.3
 rl0: <RealTek 8139 10/100BaseTX> rev 0x10 int a irq 10 on pci0.14.0
 rl0: Ethernet address: 00:a0:d2:1a:65:3a
 rl0: autoneg complete, link status good (half-duplex, 10Mbps)
 Probing for devices on PCI bus 1:
 vga0: <Matrox model 1001 graphics accelerator> rev 0x02 int a irq 9 on 
 pci1.0.0
 Probing for devices on the ISA bus:
 sc0 on isa
 sc0: VGA color <8 virtual consoles, flags=0x0>
 atkbdc0 at 0x60-0x6f on motherboard
 atkbd0 irq 1 on isa
 psm0 irq 12 on isa
 psm0: model MouseMan+, device ID 0
 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa
 sio0: type 16550A
 sio1: configured irq 3 not in bitmap of probed irqs 0
 sio1 not found at 0x2f8
 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
 fdc0: FIFO enabled, 8 bytes threshold
 fd0: 1.44MB 3.5in
 wdc0 at 0x1f0-0x1f7 irq 14 on isa
 wdc0: unit 0 (wd0): <QUANTUM FIREBALLlct08 26>
 wd0: 24833MB (50859648 sectors), 50456 cyls, 16 heads, 63 S/T, 512 B/S
 wdc0: unit 1 (wd1): <QUANTUM FIREBALL CR6.4A>
 wd1: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S
 wdc1 at 0x170-0x177 irq 15 on isa
 wdc1: unit 0 (atapi): <CD-532E-B/2.0A>, removable, accel, ovlap, dma, iordis
 acd0: drive speed 5512KB/sec, 128KB cache
 acd0: supported read types: CD-R, CD-RW, CD-DA, packet track
 acd0: Audio: play, 256 volume levels
 acd0: Mechanism: ejectable tray
 acd0: Medium: no/blank disc inside, unlocked
 ppc0 at 0x378 irq 7 on isa
 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
 ppc0: FIFO with 16/16/8 bytes threshold
 ppi0: <generic parallel i/o> on ppbus 0
 plip0: <PLIP network interface> on ppbus 0
 vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa
 npx0 on motherboard
 npx0: INT 16 interface
 sb0 at 0x220 irq 7 drq 1 on isa
 sb0 not attached due to irq conflict with ppc0 at 7
 changing root device to wd0s2a
 % df
 Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
 /dev/wd0s2a    396895    21381   343763     6%    /
 /dev/wd0s2f   1984479   449117  1376604    25%    /usr
 /dev/wd0s2e    595383     2144   545609     0%    /var
 /dev/wd0s2g   3870606  1164267  2396691    33%    /home/user1
 /dev/wd0s2h   3870606        3  3560955     0%    /home/user2
 /dev/wd0s2d   3765590  3219000   245343    93%    /home/user3
 /dev/wd1s2f   1488607   462986   906533    34%    /fs/mnt1
 /dev/wd1s2g    457095   415760     4768    99%    /fs/mnt2
 procfs              4        4        0   100%    /proc
 
 
 Thanks.
 
 Bo
 
 
 >From: David Greenman <dg@root.com>
 >Reply-To: dg@root.com
 >To: boxiao63@hotmail.com
 >CC: freebsd-gnats-submit@FreeBSD.ORG
 >Subject: Re: bin/18485: Dont let filesys go over 4G if not supported
 >Date: Wed, 10 May 2000 12:36:39 -0700
 >
 > >>Description:
 > >Since 32 bit couter only go as high as 4.2G, no filesys over
 > >that size should be allowed. With today's disk size, users
 > >will attempt to do just that. Either labeling or newfs should
 > >catch it.
 > >
 > >Many unexpected/unpredictable error happen when using the fs
 > >portion beyond a 32 bit counter can count.
 >
 >    There are many production filesystems that are much much larger than 
 >that
 >and have no problems. Can you be more specific about the trouble you are
 >having? FreeBSD uses 64bit ints to store things that can be larger than
 >32bits.
 >
 >-DG
 >
 >David Greenman
 >Co-founder, The FreeBSD Project - http://www.freebsd.org
 >Creator of high-performance Internet servers - http://www.terasolutions.com
 >Pave the road of life with opportunities.
 
 ________________________________________________________________________
 Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
 
 

From: David Greenman <dg@root.com>
To: "Bo Xiao" <boxiao63@hotmail.com>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/18485: Dont let filesys go over 4G if not supported 
Date: Tue, 06 Jun 2000 11:49:51 -0700

 >I am using a Celeron 400. dmesg follows. Only thing I can think
 >of is that I was also using a win98 with large partition(>2,8G)
 >enabled. The two seem to disturb each other. I turned that off
 >now. Could it be a msdos filesystem support issue?
 
    Yes, it could definately be caused by the msdos filesystem code corrupting
 your FFS partition. I thought we fixed that bug, however.
 
 -DG
 
 David Greenman
 Co-founder, The FreeBSD Project - http://www.freebsd.org
 Manufacturer of high-performance Internet servers - http://www.terasolutions.com
 Pave the road of life with opportunities.
 
>Unformatted:
