Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:4761 comp.os.linux.misc:33180
Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!agate!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!news.provo.novell.com!park.uvsc.edu!news
From: Terry Lambert <terry@cs.weber.edu>
Subject: Re: Limits on Linux, FreeBSD and NetBSD
Organization: Utah Valley State College, Orem, Utah
Date: Tue, 10 Jan 1995 03:07:14 GMT
Message-ID: <D26603.FzH@park.uvsc.edu>
X-Nntp-Posting-Host: hecate.artisoft.com
References: <pwdD25Htq.58A@netcom.com>
Sender: news@park.uvsc.edu (System Account)
Lines: 66
pwd@netcom.com (Philip W. Dalrymple III) wrote:
] We just ran into a limit on Interactive Unix and I would like to know
] what these limits on Linux, FreeBSD and NetBSD for Intel Systems are:
]
] Max number of I nodes per file system (unsigned int on Interactive)
] Max Size of any one file system (about 2000 Meg on Interactive)
] Max number of disks On the system
] Max hardware size (SCSI) of any one disk.
The MAX disk size on SCSI is fixed; if you don't like it, you'll
have to discover a standard other than SCSI -- actually, I think
the 8G limit of SCSI isn't surpassed by anything on a PC, but I
could be wrong (correct me, correct me!).
The number of disks on the system, for SCSI disks, is related to
the number of controllers you are willing to purchase, the number
of free interrupts you can give to them, and the number of LUN's
supported for each of the 7 available non-controller targets on
each bus.
This, in turn, is determined by your LUN demuxxing hardware that
you buy, and how willing you are to have one device inaccessable
while another device is in use on the same target but a different
LUN.
If you're willing to accept some delays, you can have a *very* large
number of devices on a machine.
The File suze limiti is based on the value of off_t, which is a
signed 32 bit value on Interactive UNIX (signed because lseek/tell
have to be able to return -1 to signal an error, so it loses a bit
of resoloution, putting the limit at 2^31). This is not true of
newer systems, like the DEC OSF/1 for the DEC Alpha, which has a
64 bit (or 2^63) limit.
BSD4.4 based systems also have a 64 bit off_t; however, the current
NetBSD and FreeBSD sources do not consistently used these values
throughout. This is expected to be corrected in future releases of
both systems -- or you can get them, correct it yourself, and
contribute the diffs back (or maintain them yourself).
The maximum number of inodes is dictated by the per file system
type ino_t size and the internal use of ino_t (whether it is used
as a signed value to allow error returns, or if there is a seperate
error channel for error returns). Typical implementation is as a
32 bit unsigned value, yielding 2^32 inodes, maximum. In a UFS
file system, the inode size is 128 bytes (this is true for UnixWare
and other Sun and SVR4 UNIX implementations), so the practical limit
is really how many inodes you can fit on a disk before you run out
of room. Given the 8G limit on SCSI disk size, this works out to
~16M of nothing but inodes (an impossible situation anyway, since
directory inodes will consume data per directory entry).
There is also a realistic limit on the number of file systems
imposed by the number of bits allowed per device and the number
of minor number bits, and the internal decoding of minor numbers
per device and the relationship of that decoding to the device
LUN, etc.. The current *BSD limit is 8 devices (a-h) per LUN, if
they are decoded that way in the driver.
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.