Date: Wed, 11 Jun 1997 17:58:14 +1000 From: Bruce Evans <bde@zeta.org.au> To: fs@FreeBSD.ORG, sef@Kithrup.COM Subject: Re: file size limits question Message-ID: <199706110758.RAA07387@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199706110758.RAA07387>