![[Return to Library]](BOOKSHELF.GIF)
![[Contents]](TOC.GIF)
![[Previous Chapter]](REW.GIF)
![[Next Section]](NEXT.GIF)
![[Next Chapter]](FF.GIF)
![[Index]](INDEX.GIF)
![[Help]](HELP.GIF)
This section lists the maximum system limits for the major components of this release. For hardware information specific to your individual processor, see the Software Product Description (SPD) and the Systems and Options Catalog. For information on how to tune system parameters, see the System Tuning and Performance Management guide and the System Administration guide.
| Files per archive: | No limit |
| Files per file system: | No limit |
| File size: | 4 GB |
| File name size: | 256 bytes |
| Files per archive: | Not used |
| Files per file system: | Not used |
| File size: | 4 GB |
| File name size: | Not used |
| Files per archive: | 4 GF |
| Files per file system: | 4 GF |
| File size: | 4 GB |
| File name size: | No limit (part of the inode data) |
| Files per archive: | No limit |
| Files per file system: | No limit |
| File size: | 4 GB |
| File name size: | 256 bytes (with prefix) |
In this release there are two types of disk device access: raw or character and block or buffered.
For raw or character access, the structure field uio.uio_offset 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 that is the data transfer start position. The physical block/sector number is limited by the structure field buf.b_blkno.
For block or buffered access,
the structure field
buf.b_blkno
describes the block/sector offset within the disk partition
and is a signed 32-bit value.
Since
this release
supports
a fixed 512-byte block/sector
size defined by
DEV_BSIZE,
the offset is limited to
1 TB.
Devices are described by a major-minor pair of numbers, where the major number describes the device driver and the minor number describes the device. In this release these pairings are 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 (12 bits). Since each device driver requires 12 bits for its major number, 4096 device drivers may be configured into the system.
The minor number portion of dev_t consists of bits 0 to 19 (20 bits). The content of these bits is left up to the device driver. A device driver utilizing all 20 bits for device addressing could address up to 1048576 devices per major number. For device drivers supporting disk devices, some number of bits in the minor device number will be reserved for the partition number. This release requires disk drivers to reserve the lower 6 bits for device attributes and partition numbers. However, This release restricts support to 8 partitions.
Common Access Method (CAM) is an ANSI-proposed standard for a common software interface to Small Computer Systems Interface (SCSI). There are no restrictions or limitations within CAM for disk block addressing; 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 has 4 bytes reserved for the disk block address. This is an unsigned 32-bit value allowing 2^32 - 1 or 4 Gigasectors of addressing, which corresponds to 2 TB given the 512-byte block/sector size.
In this release the SCSI/CAM driver can address a maximum of 64 buses, with up to 7 device targets per bus, and a maximum of 8 LUNs per device target. As a result, in this release, SCSI/CAM can address a maximum of 3584 devices.
This release
supports three
Redundant Array of Independent Disks (RAID)
controllers:
two for the SCSI bus
(HSZ10 and HSZ40)
and one for the EISA
or PCI bus
(SWXCR).
Each
RAID device
is seen by the
operating system
as a single target device
(that is, as a single disk)
with up to 8 Logical Unit Numbers (LUNs)
on the SCSI
controllers and
8 Logical Units (LUs) on the EISA or PCI controller,
regardless of the number of disks on each RAID device.
The HSZ10 SCSI RAID controller supports a maximum of 35 back-end disks; the HSZ40 SCSI RAID controller, a maximum of 42 back-end disks. As a result of hardware constraints, the maximum number of HSZ10 disks that can be concatenated into a logical volume is 5; the maximum number of HSZ40 disks that can be concatenated into a RAID 0 set for a logical volume is 14 with a total size limit of 32 GB.
The EISA and PCI RAID controllers supports a maximum of 8 Logical units with a maximum of 8 drive groups. A Logical Unit refers to 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 operate (defined and addressed) as a single unit. Logical volume sizes are not fixed sizes as compared to other disk devices. The size of a logical volume is configurable based on needs with a total size limit of 32 GB. In addition, the SWXCR controller may have either a one or a three channel SCSI adapter which supports 7 or 21 back-end SCSI disks, respectively. In addition, the SWXCR controller may have either one or three SCSI channels which support 7 or 21 back-end SCSI disks, respectively.
Although RAID theoretically increases the number of addressable disks significantly, Digital recommends that the maximum number of devices for each system - even with RAID configured - should not exceed the numbers listed in the following section on device limits per processor.
The disklabel defines the partitions of a disk and their starting block/sector number. The starting block/sector number of a partition is defined by the structure field partition.p_offset, which is an unsigned 32-bit value allowing 2 TB of addressing with a 512-byte block/sector size.
Note that DSA supports a maximum of 96 RA/TA devices.
(1 Baseboard PCI) + (2 PCI SCSI Adapters) = 3 SCSI Buses * 7 devices/bus
(1 Baseboard PCI) + (3 PCI SCSI Adapters) = 4 SCSI Buses * 7 devices/bus
(1 Baseboard PCI) + (4 PCI SCSI Adapters) = 5 SCSI Buses * 7 devices/bus
(1 Baseboard PCI) + (3 PCI SCSI Adapters) = 4 SCSI Buses * 7 devices/bus
(4 Single SCSI Adapters) = 4 SCSI buses * 7 devices/bus
(4 Single SCSI Adapters) = 4 SCSI buses * 7 devices/bus
(1 PCI Baseboard Single SCSI) + (3 Single SCSI PCI Adapters) +
(1 EISA Baseboard Single SCSI) + (2 Tri-SCSI Adapters) =
6 SCSI buses * 7 devices/bus
(8 PCI slots, each supporting 1 SCSI adapter) + (3 EISA slots, 1 SCSI internal)
(1 Baseboard Dual SCSI) + (6 Dual SCSI TURBOchannel Adapters) = 14 SCSI buses * 7 devices/bus
(1 Baseboard Dual SCSI) + (3 Dual SCSI TURBOchannel Adapters) = 8 SCSI buses * 7 devices/bus
(1 Baseboard Dual SCSI) + (2 Dual SCSI TURBOchannel Adapters) = 6 SCSI buses * 7 devices/bus
(1 Baseboard Dual SCSI) + (6 Dual SCSI TURBOchannel Adapters) = 14 SCSI buses * 7 devices/bus
(1 Baseboard Dual SCSI) + (5 Dual SCSI TURBOchannel Adapters) = 12 SCSI buses * 7 devices/bus
(1 Baseboard Dual SCSI) + (3 Dual SCSI TURBOchannel Adapters) = 8 SCSI buses * 7 devices/bus
(1 Baseboard Dual SCSI) + (2 Dual SCSI TURBOchannel Adapters) = 6 SCSI buses * 7 devices/bus
(1 Baseboard Single SCSI) + (2 Dual SCSI TURBOchannel Adapters) = 5 SCSI buses * 7 devices/bus
(1 Baseboard Single SCSI) = 1 SCSI bus * 7 devices/bus
28 RZ/TZ Devices
(4 Baseboard Single SCSI) = 4 SCSI buses * 7 devices/bus
96 RA/TA Devices (DSA)
112 RZ/TZ Devices (SCSI)
(8 Dual SCSI XMI Adapters) = 32 SCSI buses * 7 devices/bus
| AlphaStation 200 series: | 1 |
| AlphaStation/Server 400 series: | 1 |
| AlphaStation/Server 600 series: | 1 |
| AlphaServer 1000 series: | 1 |
| AlphaServer 2000: | 2 |
| AlphaServer 2100: | 4 |
| AlphaServer 2100A: | 4 |
| AlphaServer 8200: | 6 |
| AlphaServer 8400: | 12 |
| DEC 2000 series: | 1 |
| DEC 2100 series: | 4 |
| DEC 3000 series: | 1 |
| DEC 4000 series: | 2 |
| DEC 7000/10000 series: | 6 |
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.
In LSM, the term volume describes a virtual disk representing an addressable range of disk blocks used by applications such as file systems or databases. This release supports a maximum of 512 GB of disk space in a disk group or on a system, with a maximum supported volume of 512 GB. The maximum number of supported LSM volumes is 4093 for all disk groups in a 4093 for all disk groups in a system: 4091 non-system volumes and 2 system (root/swap) volumes.
In LSM, the term plex describes the physical disk or disks that contain a complete copy of a volume's data. So, for example, a mirrored volume would be made up 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).
In LSM, the term subdisk describes a contiguous portion of a physical disk which can be striped or concatenated together to form a plex. A maximum of 4096 subdisks can be associated with one plex, and Digital supports 4096 subdisks per disk group or per system.
LSM object names (such as volumes, plexes, subdisks, disk groups), volume attribute names (such as user and group), and dxlsm view names are limited to 14 characters.
In the Advanced File System (AdvFS), a volume is any single logical device which can be a partition on a physical disk or a logical volume. A domain is a named set of bound volumes on which filesets are placed. A fileset is a named collection of files that is bound to a single domain. An active fileset is a fileset that has been mounted, like a mounted UFS file system, for example.
Although the architectural maximum limit of domains is 2048, in this release the AdvFS supports a maximum fileset and file size of 512 GB, up to 100 active file domains per system, and a maximum of 256 volumes per domain.
Since a single disk failure in a domain can make the entire domain inaccessible, Digital also recommends that you create no more than 8 volumes per domain.
Note that while Digital UNIX supports an unlimited number of filesets per system, only 512 filesets can be mounted at one time.
The number of files per fileset is
2^32,
limited by the tag used to uniquely identify a file in a
fileset.
Note that over time the actual limit of files per fileset decreases, since a tag can only be used 4096 times due to a sequence number limit.
Although AdvFS can support page sizes larger than 13 bits, the theoretical maximum AdvFS file and fileset size is 16 TB (2^32 * 2^31) with a 13-bit page size and 31-bit page number.
In
this release,
the UNIX File System (UFS) file size is limited by the
amount of space that the kernel
buf
structure can address.
The structure field
buf.b_blkno,
defined as
daddr_t,
is the block/sector offset within a disk partition
and is a 32-bit signed value.
The block or sector
size,
DEV_BSIZE,
is 512 bytes.
As a result, the theoretical maximum file system
size that
this release
supports is
1 TB
(2^31 * $2^9).
Note that
Digital only supports
128 GB.
The UFS file system
and file size is limited by the maximum logical volume size
supported by the Logical Volume Manager.›
(the maximum logical volume size supported by the Logical Storage Manager).
The size of the CD-ROM File System (CDFS) files and file systems is limited by the compact read-only optical disk (CD-ROM) media where they reside. Currently, the CD-ROM media supports approximately 0.60 GB. However, Digital UNIX is able to support larger CD-ROMs should they become available.
Digital UNIX supports sparse files on AdvFS and UFS, which means that the size of a file may exceed the size of the file system where it resides. Digital UNIX supports the following maximum sizes for sparse files:
| AdvFS | 2^43 + 2 |
| UFS | 2^44 - 8 |
In this release, the theoretical maximum size of a file that is accessible through the Network File System (NFS) is as follows:
Digital supports the following maximum file sizes:
Note that an NFS server is always limited by the size of the underlying local file system.
The supported maximum size of a file that can be mapped into memory without segmenting the file is 1 GB.
The Advanced File System (AdvFS) supports a maximum of 512 mounted filesets. However, each active domain has an invisible mounted fileset associated with it which must be factored into the total number of mounted filesets. So, for example, if you have an active domain with two mounted filesets, the invisible fileset associated with the domain itself brings the total number of mounted filesets to three.
The UNIX File System (UFS) supports a total of 512 mounts, which are now allocated dynamically by the system rather than being dependent on statically configured mount tables as they were in previous releases of the operating system.
this release supports a maximum of 512 CD-ROM File System (CDFS) mounts.
A Network File System (NFS) Version 2.0 or Version 3.0 client can mount a maximum of 2048 files or directories. The vnodes necessary to support the NFS-mounts are now allocated dynamically rather than being dependent on a statically configured vnode table as they were in previous releases of
The maximum number of files a process can open is set to 4096 by default in the OPEN_MAX_SYSTEM variable in the file /usr/sys/include/sys/param.h. This number can be adjusted between 64 and 4096, either in individual programs by using the setrlimit(2) system call or on a system-wide basis by editing the file /usr/sys/conf/param.c, changing the open_max_soft and open_max_hard variables, and then relinking or rebuilding the kernel. Note that 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. Note that since the NFS Version 2 protocol suite only allows ranges to be specified 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.
This section lists the disk space required for root, /usr, and /var when performing a default or a custom installation of this release. These are approximate numbers, as the values will depend on the system configuration and are based on the UFS files system.
| root: | |
| 39.7 MB | |
| /usr: | |
| 168.4 MB |
| root: | |
| 49.1 MB | |
| /usr: | |
| 333.7 MB | |
| /var: | |
| 6.1 MB |
The maximum supported memory is different for each individual processor, although the DEC 7000/10000/8200/8400 series a total of 14 GB of physical memory. The operating system, however, supports a total of approximately 4 GB of physical memory.
For more information on supported memory,
see the
Systems and Options Catalog.
and the
SPD.
The default virtual memory per process is 2 GB, although available swap space may in many cases be exhausted before this limit is reached.
This value can be increased to a maximum of 8 TB by defining the MAXVAS variable in the system configuration file and relinking or rebuilding the kernel.
The default page size is 8 KB and is not configurable. The page size is hardware dependent and is set up by the console at boot time.
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, where each device can be displayed using ifconfig -a.
For information on network transfer rates, see the Technical Overview.
The number of processes per system depends on the value of MAXUSERS, which is configurable and set in the configuration file to 32 by default. With MAXUSERS at its default value, the number of processes per system is set to 276 in the NPROC variable in /usr/sys/conf/param.c.
You can increase this value by either changing the value of MAXUSERS in the system configuration file or by adding the maxproc variable to the system configuration file and relinking or rebuilding the kernel.
You might increase the value
of
MAXUSERS
to allow more
users to log in to your system or to allow
applications that run as
root
to fork more processes
than
NPROC
allows by default.
However,
increasing
the number of
processes per system
reserves more system
memory,
so
the upper limit of
NPROC
is dependent upon the
system's total memory,
the number of actual users on the
system,
and the requirements of your applications.
The number of processes that each user can fork is set to 64 by default through the CHILDMAX variable in the file /usr/sys/include/sys/syslimits.h. The number of processes per user can be varied by adding the maxuprc variable to the system configuration file, setting its value to some number of processes, and then relinking or rebuilding the kernel.
You might increase this value if you had an application that needed more processes than CHILDMAX is set to by default. However, increasing the value of maxuprc reserves more system memory, so the upper limit of maxuprc is dependent upon the system's total memory, the number of actual users on the system, and the requirements of your applications.