This chapter includes:
Neutrino is a microkernel, so many things that might be a core limit in some operating systems, become dependent on the particular manager that implements that service under Neutrino, especially for filesystems, where there are multiple possible filesystems.
Many resources depend on how much memory is available. Other limits depend on your target system. For example, the virtual address space for a process can vary by processor from 32M on ARM to 3.5G on x86.
Some limits are a complex interaction between many things. To quote the simple/obvious limit is misleading; describing all of the interactions can be complicated. The key thing to remember while reading this chapter is that there can be many factors behind a limit.
When you're trying to determine your system's limits, you can get the values of configurable limits, special read-only variables that store system information.
|Neutrino also supports configuration strings, which are similar to, and frequently used in conjunction with, environment variables. For more information, see the Configuring Your Environment chapter.|
You can use the POSIX getconf utility to get the value of a configurable limit or a configuration string. Since getconf is a POSIX utility, scripts that use it instead of hard-coded QNX-specific limits can adapt to other POSIX environments.
Some configurable limits are associated with a path; their names start with _PC_. When you get the value of these limits, you must provide the path (see "Filesystem limits," below). For example, to get the maximum length of the filename, type:
getconf _PC_NAME_MAX pathname
Other limits are associated with the entire system; their names start with _SC_. You don't have to provide a path when you get their values. For example, to get the maximum number of files that a process can have open, type:
In general, you can't change the value of the configurable limits -- they're called "configurable" because the system can set them.
The Neutrino libraries provide various functions that you can use in a program to work with configurable limits:
Under Neutrino, filesystems aren't part of the kernel or core operating system; they're provided by separately loadable processes or libraries. This means that:
The sections that follow give the limits for the supported filesystems. Note the following:
You can query the path-specific configuration limits to determine some of the properties and limits of a specific filesystem:
For more information, see "Configurable limits," above.
The limits for QNX 4 filesystems include:
The limits for Linux Ext2 filesystems include:
The limits for DOS FAT12/16/32 filesystems include:
These filesystems don't really support permissions, but they can emulate them.
The limits for CD-ROM (ISO9660) filesystems include:
The limits for NFS2 and NFS3 filesystems include:
The limits for CIFS filesystems include:
The CIFS filesystem doesn't support chmod or chown.
The limits for embedded (flash) filesystems include:
File entries, directory entries, and file extents are connected by linked lists. The longer these lists get, the longer it takes to seek for a position in, append to, and get statistics about files.
These limits apply to the entire system:
These limits apply to each process:
Priority 0 is used for the idle thread; by default, priorities of 64 and greater are privileged, so only processes with an effective user ID of 0 (i.e. root) can use them. Non-root processes can use priorities from 1 through 63.
You can change the range of privileged priorities with the -P option for procnto.
The total number of file descriptors has a hard limit of 32767 per process, but you're more likely to be constrained by the -F option to procnto or the RLIMIT_NOFILE system resource. The default value is 1000; the minimum is 100.
|Sockets, named semaphores, message queues, channel IDs (chids), and connection IDs (coids) all use file descriptors.|
To determine the current limit, use the ksh builtin command, ulimit, (see the Utilities Reference), or call getrlimit() (see the Library Reference).
There are no limits on the number of mutexes and condition variables (condvars).
There's no limit on the number of unnamed semaphores, but the number of named semaphores is limited by the number of available file descriptors (see "File descriptors," above).
The number of open connections and sockets is limited only by memory and by the maximum number of file descriptors per process (see "File descriptors," above).
The number of shared memory areas is limited by the allowed virtual address space for a process, which depends on the target architecture. See the RLIMIT_AS and RLIMIT_DATA resources for setrlimit() in the Library Reference.
The number of message queues is limited by the number of available file descriptors (see "File descriptors," above).
The default maximum number of entries in a queue, and the default maximum size of a queue entry depend on whether you're using the traditional (mqueue) or alternate (mq) implementation of message queues:
|Number of entries||1024||64|
For more information, see mqueue and mq in the Utilities Reference, and mq_open() in the Neutrino Library Reference.
|System RAM||64G (36-bit addressing)||64G (36-bit addressing)||1T (40-bit addressing)||512M (29-bit addressing)||4G (32-bit addressing)|
|Virtual address space+||3.5G||3G||2G||2G||32M|
* The hardware might further limit the number of CPUs.
+ These are the absolute maximum limits for the virtual address space; you can reduce them by setting the RLIMIT_AS resource with setrlimit().