This appendix lists the system limits for the major components of this release. For hardware information specific to your individual processor, see the DIGITAL UNIX Software Product Description (SPD) and the DIGITAL Systems & Options Catalog.
You may be able to increase some of the system limits by changing
kernel attribute values. Use the
sysconfig
command to display the current attribute values, and the maximum and
minimum values.
For information on how to modify attributes, see the
System Administration
manual and the
System Configuration and Tuning
manual, which also includes a list of tunable attributes.
The following sections describe the system limits.
A default installation of the DIGITAL UNIX operating system requires at least 525 MB of disk space (for example, a RZ25 disk). This limit will change in a future release (see Section 8.27 for more information). The disk space that a custom installation requires depends on the optional subsets that you will install. See Appendix B for information about subset sizes.
The memory limits are as follows:
The minimum amount of physical memory that DIGITAL UNIX requires is 24 MB, or 32 MB if you are using the Advanced File System (AdvFS). However, depending on the configuration and workload, you may need at least 64 MB for optimal performance.
The system platform limits the maximum amount of physical memory. For more information on platform memory support, see the DIGITAL Systems & Options Catalog.
The default amount of virtual address space available for each process is 1 GB. However, in many cases, available swap space may be exhausted before this limit is reached.
You can increase the available virtual address space to a maximum
of 4 TB by modifying the value of the
vm-maxvas
attribute in the
vm
subsystem. For more information about setting this attribute, see the
System Configuration and Tuning
guide.
The physical page size is 8 KB and cannot be changed. The page size is hardware dependent and is set by the console at boot time.
The process limits for the system and for users are as follows:
The
maxusers
attribute in the
proc
subsystem specifies the number of simultaneous
users that a system can support without straining system resources. System
algorithms use the
maxusers
attribute to size various system
data structures, and to determine the amount of space allocated to system
tables, such as the system process table, which is used to determine how many
active processes can be running at one time.
The default value assigned to the
maxusers
attribute
depends on the size of your system. The default value is 32 on systems
with at least 32 MB of
physical memory. The minimum value is 8 and the maximum value is 4096.
The maximum number of tasks that can run simultaneously on a system
is determined by the value of the
task-max
attribute in the
proc
subsystem. The default value is 8213. The minimum value is 85,
and the maximum value is 32768.
The maximum number of kernel threads that can run simultaneously
on a system is determined by the value of the
thread-max
attribute in the
proc
subsystem. The default value is 16424. The minimum value is 160,
and the maximum value is 262136.
The maximum number of processes that a user can create is determined by the
value of the
max-proc-per-user
attribute in the
proc
subsystem. The default value is 64. The minimum value is 0, and the
maximum value is 32767.
The maximum number of threads that a user can create
is determined by the value of the
max-threads-per-user
attribute in the
proc
subsystem. The default value is 256. The minimum value is 0, and the
maximum value is 18,446,744,073,709,551,615
(2^64 - 1).
The limits for device addressing are as follows:
There are two types of disk device access: raw (character) and buffered (block).
For raw or character access, the
uio.uio_offset
structure field
describes the byte offset within the disk partition. In this release, the
uio_offset
is an
unsigned 64-bit value, allowing an offset up to
2^64
or 18 exabytes.
This value is converted to a
physical block/sector number, which is the data transfer start position. The
physical block/sector number is limited by the
buf.b_blkno
structure field.
For buffered or block access, the
buf.b_blkno
structure field describes the block/sector offset within the disk partition
and is a signed 32-bit value. Because this release supports a fixed
512-byte block/sector size, as defined by
DEV_BSIZE
,
the offset is limited to 1 TB.
dev_t
)
Devices are identified by a major-minor pair of numbers,
where the major number specifies the device driver
and the minor number identifies the device. In this release, this pairing
is represented by a 32-bit value described by the type
dev_t
.
The major number portion of
dev_t
consists of bits 20 to 31 (a total of 12 bits). Because each device
driver requires 12 bits for its major number, you can configure only 4096
device drivers into the system.
The minor number portion of
dev_t
consists of bits 0 to 19 (a total of 20 bits). The device driver is
responsible for interpreting these bits.
A device driver that utilizes all 20 bits for device addressing can
address up to 1048576 devices for each major number. For device
drivers that support disk devices, some of the bits in the minor
device number represents the partition number. This
release requires disk drivers to reserve the lower 6 bits for
device attributes and partition numbers, and only supports eight partitions.
Common Access Method (CAM) is an ANSI-proposed standard for a common software interface to the Small Computer Systems Interface (SCSI). There are no restrictions or limitations within CAM for disk block addressing, because the address is an incoming value.
For SCSI-2, the Command Descriptor Block (CDB) defines the starting disk block number for the transfer. In this release, the 10-byte CDB reserves 4 bytes for the disk block address. This is an unsigned 32-bit value that allows 2^32 - 1 or 4 gigasectors of addressing. Using a 512-byte block/sector size, this value corresponds to 2 TB.
In this release, the SCSI/CAM driver can address a maximum of 64 buses, with up to 7 device targets for each bus, and a maximum of eight logical unit numbers (LUNs) for each device target. According to these limitations, SCSI/CAM can address a maximum of 3584 devices.
This release supports five RAID controllers. The HSZ10, HSZ20, HSZ40, and HSZ50 controllers utilize SCSI buses. The SWXCR controller utilizes an EISA or PCI bus.
The operating system sees a RAID controller as a single target device (that is, as a single disk) that has up to eight LUNs (for the SCSI RAID controllers) or eight Logical Units (LUs) (for the EISA or PCI controller), regardless of the number of disks connected to each controller.
The HSZ10 controller supports a maximum of 35 backend disks. Because of hardware constraints, a maximum of five HSZ10 disks can be concatenated into a logical volume.
The HSZ20 controller supports a maximum of 14 backend disks.
The HSZ40 and HSZ50 controllers support a maximum of 42 backend disks. You can concatenate into a RAID 0 set a maximum of 14 HSZ40 disks with a maximum total size of 32 GB.
The SWXCR controller supports a maximum of eight LUs, each with a maximum of 8 drive groups. An LU represents an amount of storage space presented to the host operating system as a single storage device. A drive group consists of one to eight physical drives that are defined and addressed as a single unit. Logical volumes do not have fixed sizes. You can configure the size of a logical volume, as needed, up to a maximum of 32 GB. In addition, the SWXCR controller can have either one SCSI channel or three SCSI channels that support 7 or 21 backend SCSI disks, respectively.
Although RAID significantly increases the number of addressable disks, DIGITAL recommends that the maximum number of devices connected to a system - even with RAID controllers - does not exceed the limit specified in the section on processor device limits.
The
disklabel
command specifies the partitions of a disk and their starting
block/sector number. The starting block/sector number of a
partition is defined by the
partition.p_offset
structure field, which is an unsigned 32-bit value that
supports up to 2 TB of addressing, using a 512-byte block/sector size.
DIGITAL UNIX supports a maximum of seven devices per SCSI bus (for example, one host bus adapter and seven disks). The maximum number of SCSI buses supported by a system depends on the platform, but the DIGITAL UNIX operating system supports a maximum of 64 SCSI buses.
For all other device limits, see the DIGITAL Systems & Options Catalog.
In this release, the Logical Storage Manager (LSM), supports a maximum of 768 disk groups and 256 disks, either in a disk group or across the system.
The LSM term volume refers to a virtual disk that represents an addressable range of disk blocks. File system data or raw I/O can be directed to a volume. This release supports a maximum of 512 GB of disk space in a disk group or on a system, and a maximum volume size of 512 GB. The maximum number of supported LSM volumes is 4093 for all disk groups in a system, which includes 4091 nonsystem volumes and 2 system (root or swap) volumes.
The LSM term plex refers to a physical disk or a set of disks that contain a complete copy of a volume's data. A mirrored volume consists of at least two plexes. In this release, the maximum number of supported plexes per volume is 8, and the maximum number of supported plexes per system is 4093 (or 4091, if root and swap volumes are not used).
The LSM term subdisk refers to a contiguous portion of a physical disk that can be striped or concatenated with other subdisks to form a plex. A maximum of 4096 subdisks can be associated with one plex, and DIGITAL supports 4096 subdisks in each disk group or on a system.
LSM object names (for example, volumes, plexes, subdisks, and disk
groups), volume attribute names (such as user and group), and
dxlsm view
names are limited to 14 characters.
The file system limits are as follows:
The Advanced File System (AdvFS) term volume refers to a single logical device, such as a disk, disk partition, or a logical volume. A file domain is a named set of one or more volumes. A fileset is a named and mountable logical file structure that is created in a domain. An active fileset is a fileset that is currently mounted.
AdvFS supports a maximum fileset and file size of 16 TB minus 512 K, a maximum of 100 active file domains for each system, and a maximum of 256 volumes for each domain. However, because a single disk failure in a multivolume file domain can make the entire domain inaccessible, DIGITAL recommends that you use a maximum of eight volumes in a file domain.
Although DIGITAL UNIX supports an unlimited number of filesets per system, only 512 filesets can be mounted at one time. The maximum number of files in a fileset is 2^31 and is limited by the tag that is used to uniquely identify a file in a fileset. Because of a sequence number limit, a tag can be used only 4096 times; therefore, the actual limit on files in a fileset decreases over time.
Although AdvFS can support a page size larger than 13 bits, the maximum size of an AdvFS file and fileset is 16 TB - 512 K (2^32 * 2^31), with a 13-bit page size and a 31-bit page number.
AdvFS supports a maximum of 512 mounted filesets. However, each active file domain has a hidden mounted fileset that must be counted when determining the total number of mounted filesets. For example, if you have an active file domain with two mounted filesets, the file domain actually has three mounted filesets.
In this release,
the UNIX File System (UFS) file size is limited by the
amount of space that can be addressed by the kernel
buf
structure. The
buf.b_blkno
structure field, defined as
daddr_t
,
is a 32-bit signed value, and specifies the block/sector offset
within a disk partition. The
DEV_BSIZE
,
block or sector size,
is 512 bytes. Theoretically, a UFS file system could be 1 TB
(2^31 * 2^9);
however, DIGITAL UNIX supports only 128 GB.
The maximum LSM logical volume size also limits a UFS file system
and file size.
DIGITAL UNIX supports up to 2,147,483,647 UNIX File System (UFS) and
Memory File System (MFS) mounts. The
max-ufs-mounts
attribute controls the maximum number of UFS and MFS mounts. The
default value is 1000.
The size of CD-ROM File System (CDFS) files and file systems is limited by the CD-ROM media in which they reside. Currently, the CD-ROM media supports approximately 600 MB. However, DIGITAL UNIX will be able to support larger CD-ROMs if they become available.
This release supports a maximum of 512 CDFS mounts.
DIGITAL UNIX supports sparse files on AdvFS and UFS; therefore, the size of a file can exceed the size of the file system in which it resides. The maximum sizes for sparse files are as follows:
In this release, the theoretical maximum sizes of files that are accessible through Network File System (NFS) Version 2 and Version 3 are as follows:
However, DIGITAL UNIX supports the following maximum file sizes:
In addition, an NFS file system is always limited by the size of the local file system that is being exported.
An NFS Version 2 or Version 3 client can mount a maximum of 2048 files or directories.
The maximum supported size of a file that can be mapped into memory without segmenting the file depends on the virtual address space limits, as documented in the section on memory limits.
The
open-max-soft
and
open-max-hard
attributes control the maximum number of open file
descriptors for all processes. The default values are 4096. When the
open-max-soft
limit is reached, a warning message is issued, and when the
open-max-hard
limit is reached, the process is stopped.
The maximum number of open files per process is 65,536.
If you increase the maximum number of open files per process, make sure
that you adjust the value of the
max-vnodes
attribute.
See
Section 1.10
and
Appendix E
for information about increasing
the open file descriptor limit. In addition,
the maximum number of open files can be set, on a per-process basis,
between 64 and 4096 by using the
setrlimit
function, or up to 65,536 by following the steps documented in
Appendix E.
File descriptor entries in the per process file table
are dynamically allocated after the initial 64 entries in the
utask
structure are used.
The DIGITAL UNIX file record locking service allows applications to lock any number of bytes in a file in the range of 0 to 2^63 - 1, inclusive. File locking is supported by UFS, AdvFS, and both NFS Version 2 and Version 3. Because the NFS Version 2 protocol suite allows ranges to be specified only with 32-bit numbers, it supports a file locking range of 0 to 2^31 - 1, inclusive.
AdvFS, UFS, CDFS, and NFS support a maximum pathname component of 255 bytes and a maximum file pathname of 1023 bytes.
The networking limits are as follows:
ptys
)
The maximum number of supported
ptys
is 8192.
DIGITAL UNIX allows the use of up to 5,000 IP alias addresses before system performance begins to degrade.
The packetfilter pseudo-driver can support up to 255 simultaneous open filters
(each filter is usually mapped to one instance of an application program).
The packetfilter can support a maximum of 255 devices. Use the
pfconfig
command to configure packet filters.
For information on network transfer rates, see the Technical Overview.
The limits for the backup utilities are as follows:
cpio
Files per archive: | No limit |
Files per file system: | No limit |
File size: | 4 GB |
File name size: | 256 bytes |
dd
Files per archive: | Not used |
Files per file system: | Not used |
File size: | 4 GB |
File name size: | Not used |
dump
Files per archive: | 4,000,000,000 |
Files per file system: | 4,000,000,000 |
File size: | 4 GB |
File name size: | No limit (part of the inode data) |
tar
Files per archive: | No limit |
Files per file system: | No limit |
File size: | 8 GB (4 TB with extended option) |
File name size: | 1024 bytes (with prefix) |
pax
Files per archive: | No limit |
Files per file system: | No limit |
File size: | 8 GB (4 TB with extended option) |
File name size: | 1024 bytes (with prefix) |