Bug 18485

Summary: Dont let filesys go over 4G if not supported
Product: Base System Reporter: boxiao63 <boxiao63>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description boxiao63 2000-05-10 16:20:00 UTC
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.
Comment 1 Peter Wemm freebsd_committer freebsd_triage 2000-05-10 16:34:50 UTC
State Changed
From-To: open->closed

This is a bogus report.  We do support filesystems over 4G because 
we use 64 bit off_t's etc. 

Comment 2 David Greenman 2000-05-10 20:36:39 UTC
>>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.
Comment 3 boxiao63 2000-06-06 18:45:25 UTC
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
Comment 4 David Greenman 2000-06-06 19:49:51 UTC
>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.