Return to BSD News archive
Path: euryale.cc.adfa.oz.au!platinum.sge.net!como.dpie.gov.au!news.gan.net.au!act.news.telstra.net!vic.news.telstra.net!news.mira.net.au!news.netspace.net.au!news.melbpc.org.au!news.mel.connect.com.au!news.syd.connect.com.au!phaedrus.kralizec.net.au!godzilla.zeta.org.au!not-for-mail From: bde@zeta.org.au (Bruce Evans) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: ufs, ext2fs sizes Date: 29 Jun 1997 04:57:16 +1000 Organization: Kralizec Internet Lines: 67 Message-ID: <5p3mqc$8kl$1@godzilla.zeta.org.au> References: <33AF89E9.513B63BD@info13.polytechnique.fr> <5otrdo$dlh@ui-gate.utell.co.uk> <5ou9om$mqg$1@godzilla.zeta.org.au> <5p0i78$o4d@ui-gate.utell.co.uk> NNTP-Posting-Host: godzilla.zeta.org.au Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:43687 In article <5p0i78$o4d@ui-gate.utell.co.uk>, Brian Somers <brian@awfulhak.org, brian@utell.co.uk> wrote: >In article <5ou9om$mqg$1@godzilla.zeta.org.au>, > bde@zeta.org.au (Bruce Evans) writes: >> >> The file size is currently limited mainly by triple indirect blocks >> never actually being allocated. This gives a maximum file size of >> about 32GB for a file system with a block size of 8K. > >I don't follow. Are you saying that FreeBSD doesn't use more >than 3 levels of indirection ? If so, are there any plans to >fix it ? Actually, they work for file systems with a block size of 4K, but fail for all other (larger) block sizes because the calculation of the number of triply indirect blocks overflows. E.g., for a block size of 8192, there are (8192/4)^3 = 2^33 indirect blocks. This number doesn't fit in `long blockcnt' in ufs_getblns(). The fix is obvious. There are many similar overflow bugs in BSD4.4Lite2, but most of them have already been fixed. There is also a bug in the maxfilesize setting in newfs. The correct value is calculated, but not used. The size is hacked down to 0.5 TB to avoid overflow bugs in ufs. This is fixed in another (not quite right) way in BSD4.4Lite2, but FreeBSD still has the old hack. >Surely this is an error - AFAIK, the max file size >*should* == max partition size. Or is it intentional ? The maximum file size is not directly related to the (maximum) partition size. First, sparse files can be much larger than partitions. E.g., while fixing these bugs, I created a file of size 1TB-1 on my 32MB root partition. It took only 416K of physical blocks. Second, the filesystem block size or number of indirect blocks supported may limit the max file size more than the max partition size. Third, there is nothing to stop 64-bit block numbers being used for i/o, while ufs is inherently limited to 32-bit block numbers. >>>Eh ? A terabyte is relatively small ! What's the "full advantage" ? >> >> ext2fs has the same file system size limit as ufs for the same reasons. > >I definitely don't understand. It's unlikely that both would >suffer from the same :| The file _system_ size is limited mainly by the i/o system limits, provided the file system block size is >= the i/o system block size and file system block numbers are stored in a type that is at least as large as the type for i/o system block numbers. >> The file size for ext2fs is limited to 2^32 by the 32-bit size field >> in the inode and to 2^31 by bugs in the code. > >Ouch. Has linux fixed this (made the size an off_t) ? I'm assuming >that the code uses off_t (== long long) - otherwise of course it would >be limited to 2^31 by the signed int/long. off_t is long (32 bits signed) in Linux, so this is hard to fix. There is 16 bytes to spare for expanding i_size in the inode. >Perhaps disklabels should use a "unsigned long long" ? Are there >restrictions at a lower level ? Block numbers in partition tables also have only 32 bits. IDE disk numbers have only 28 bits. BIOS cylinder numbers have only 10 bits :-). -- Bruce Evans bde@zeta.org.au