NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/unix/bsd/8638

Internet Message Format | 1992-11-09 | 3.6 KB

Path: sparky!uunet!mcsun!Germany.EU.net!tools!ws
From: [e-mail] (Wolfgang Solfrank)
Newsgroups: comp.unix.bsd
Subject: Re: Largest file size for 386BSD ?
Date: 9 Nov 92 15:32:43
Organization: TooLs GmbH, Bonn, Germany
Lines: 65
Message-ID: <[e-mail]>
References: <[e-mail]>
    <[e-mail]>
NNTP-Posting-Host: kurt.tools.de
In-reply-to: [e-mail]'s message of 6 Nov 92 17:34:54 GMT

In article <[e-mail]> [e-mail] (A Wizard of Earth C) writes:
   In article <[e-mail]> [e-mail] (Othman Ahmad) writes:
   >
   >Original Unix has the largest file size of 4Gbyte, because it uses 24-bit
   >pointer.(shouldn't it be 16Gbyte?)

   No, 4 Gig; think of identification of indirect blocks for a total of two
   levels of indirection using a 24 bit value.

While the use of 24-bit pointers (actually block numbers) in some ancious
version (V7 up to SysV) of Unix is correct, this limits the size of the
partition and only indirectly the size of one file. The limit in the
partition size thus implied is 2^24*1024 = 16GB as the logical block
size on these partition in newer versions of SysV is 1K. Actually it could
even be larger because the 24-bit block numbers are only used for the direct
blocks. The indirect blocks use 32-bit block numbers which would extend the
possible partition size to 4TeraByte (1TB = 1024GB).

This file system had 10 direct blocks, 1 sinlge-indirect, 1 double-indirect
and 1 triple-indirect block per inode. This implies a theoretical limit
to the file size of (10 + 256 + 256*256 + 256*256*256)*1024, about 16GB.

   >What is the size for 386bsd?
   >If it still uses 24-bit pointers, then the largest size is still 4Gbyte.

   Yep.

In BSD filesystems the structure is a little different. The logical block size
is 512 bytes and the block numbers in the inode (and anywhere else) are
always 32-bit. Thus the maximum partition size is limited to 2^32*512 = 2TB.

The inode has 12 direct blocks and a similar structure of indirect blocks.
But as indirect blocks are always in terms of filesystem blocks and not
fragments, they can store, depending on filesystem block size, up to
8192/4 = 2048 block address per indirect block. This results in a theoretical
limit to the file size of (12 + 2048 + 2048*2048 + 2048*2048*2048)*512,
about 4TB.

Of course both filesystems' file (and partition) sizes are actually limited
by the file size entry in the inode, which is 32-bit (there is room in the
UFS inode for extending this to 64-bit), and by the fact that file offsets
used by lseek are signed longs. This limits the actual file size to 2GB.

   >This will be an important issue because soon we'll have hundreds of gigabytes,
   >instead of magabytes soon.
   >    It took the jump from tens mega to hundreds in just 10 years.

   Get around the problem:

   1)    Multiple partitions not exceeding the 4 Gig limit.
   2)    Larger terminal blocks.
   3)    Additional indirection levels.
   4)    Assumption of larger files = log-structure file systems (ala Sprite).

   I don't think it will be an issue that soon anyway.

As the limits to both the file size and the partition size implied by the
filesystem is large enough for quite some time (especially in the case
of the UFS, IMHO) the only change eventually required would be a modified
version of lseek. This would be far more easy to add with backward compatibility
if the now last parameter would be before the offset and not behind it in
the call structure. The noew established version seems to require a new
system call.
--
[e-mail]     (Wolfgang Solfrank, TooLs GmbH) [phone]