From owner-freebsd-fs  Wed Jun 11 01:03:19 1997
Return-Path: <owner-fs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id BAA08876
          for fs-outgoing; Wed, 11 Jun 1997 01:03:19 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA08870
          for <fs@FreeBSD.ORG>; Wed, 11 Jun 1997 01:03:15 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id RAA07387; Wed, 11 Jun 1997 17:58:14 +1000
Date: Wed, 11 Jun 1997 17:58:14 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199706110758.RAA07387@godzilla.zeta.org.au>
To: fs@FreeBSD.ORG, sef@Kithrup.COM
Subject: Re: file size limits question
Sender: owner-fs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>On my 2.2-970212-GAMMA (hey that's not a Y2k compliant name!) system, /tmp
>is an MFS filesystem; $HOME is a normal, SCSI-disk UFS filesystem.
>
>When I run this program and create a file in /tmp, it creates a file that is
>34376613888 bytes long.  When it creates a file in $HOME, it is 2147483647
>bytes long.

34... == 32G seems to be normal for ufs file systems with a block size
of 8K.  There seems to be an off by one error in ufs_getlbns(), so triply
indirect blocks are never actually allocated (i == 0 corresponds to
NIADDR = 3 levels of indirection, and EFBIG is returned when i == 0).
Thus the maximum file size is limited mainly by the number of doubly
indirect blocks == (block_size/4)^2 == 4M, to block_size^3 / 16.
block_size == 8K gives the magic 32G.

I once created a 1TB sparse file to test newfs and fsck on.  I must have
used a large block size to get there, since the bug has been present in
all versions of FreeBSD-2.x.  Version 1.1 of ufs_bmap.c even has an off
by one bug in the array dimension for nindir[].

2G must be caused by a bug somewhere else.  A block size of 4K would
give a doubly-indirect-block-limited limit of 4GB.  Perhaps there is
also a sign extension bug.

When I ran the program on a  (blocksize = 4K) ext2fs file system, it
gave a size of 4402G.  This is interesting, since the file size is stored
in 32 bits in the disk inode :-).  Unmounting and remounting the file
system reduced the size to 4243456 bytes.

>I am surprised by this difference.  Can anyone explain it, or do I have to
>dive into the device driver code?  (I am assuming that the limitation is
>going to be in the device driver, not the filesystem, given that MFS is
>essentially UFS...)

No, bugs are relatively unlikely in device drivers since they work mostly
with 31-bit block numbers and rarely see huge offsets.

Bruce