File Systems
This section introduces the file systems supported by the ChorusOS operating system. For full details of the implementation of these file systems, see "Introduction to File System Administration for ChorusOS" in ChorusOS 5.0 System Administrator's Guide.
UNIX File System (UFS)
The UNIX file system option provides support for a disk-based file system, namely, the file system resides on physical media such as hard disks.
The UNIX file system option supports drivers for the following types of physical media:
-
SCSI disks
-
IDE disks
-
RAM disks
The UFS feature provides POSIX-compatible file I/O system calls on top of the UFS file system on a local disk. Thus, it requires a local disk to be configured and accessible on the target system. At least one of the RAM_DISK, or SCSI_DISK features must be configured. UFS must be embedded in any configuration that exports local files through NFS.
The UFS feature API is identical to the API exported by the NFS_CLIENT feature. However, some system calls in this API will return with error codes since the underlying file system layout does not support all these operations. For general information on the API provided by this feature, see the POSIX standard (IEEE Std 1003.1b-1993).
UFS API
The UFS feature API is summarized in the following table. It is identical to the API exported by the NFS_CLIENT feature. However, some system calls in this API will return with error codes since the underlying file system layout does not support all these operations. For general information on the API provided by this feature, see the POSIX standard (IEEE Std 1003.1b-1993). Some of the calls listed are also included in other features.
|
Command |
Description |
|---|---|
|
access |
Check access permissions |
|
chdir, fchdir |
Change current directory |
|
chflags |
Modify file flags (BSD command) |
|
chmod, fchmod |
Change access mode |
|
chown, fchown |
Change owner |
|
chroot |
Change root directory |
|
close |
Close a file descriptor |
|
dup, dup2 |
Duplicate an open file descriptor |
|
fcntl |
File control |
|
flock |
Apply or remove an advisory lock on an open file |
|
fpathconf |
Get configurable pathname variables |
|
fsync |
Synchronize a file's in-core statistics with those on disk |
|
getdents |
Read directory entries |
|
getdirentries |
Get directory entries in a file system independent format |
|
getfsstat |
Get list of all mounted file systems |
|
ioctl |
Device control |
|
link |
Make a hard file link |
|
lseek |
Move read/write file pointer |
|
mkdir |
Make a directory file |
|
mkfifo |
Make FIFOs |
|
mknod |
Create a special file |
|
mount, umount |
Mount or unmount a file system |
|
open |
Open for reading or writing |
|
read, readv |
Read from file |
|
readlink |
Read a value of a symbolic link |
|
rename |
Change the name of a file |
|
revoke |
Invalidate all open file descriptors (BSD command) |
|
rmdir |
Remove a directory file |
|
stat, fstat, lstat |
Get file status |
|
statfs, fstatfs |
Get file system statistics |
|
symlink |
Make a symbolic link to a file |
|
sync |
Synchronize disk block in-core status with that on disk |
|
truncate, ftruncate |
Truncate a file |
|
umask |
Set file creation mode mask |
|
unlink |
Remove a directory entry |
|
utimes |
Set file access and modification times |
|
write, writev |
Write to a file |
The following library calls do not support multithreaded applications:
|
Function |
Description |
|---|---|
|
opendir() |
Open a directory |
|
closedir() |
Close a directory |
|
readdir() |
Read directory entry |
|
rewinddir() |
Reset directory stream |
|
scandir() |
Scan a directory for matching entries |
|
seekdir() |
Set the position of the next readdir() call in the directory stream |
|
telldir() |
Return current location in directory stream |
First-in, First-Out File System (FIFOFS)
The FIFOFS
feature provides support for named pipes. It requires either NFS_CLIENT or UFS to be configured as
well as POSIX_SOCKETS and AF_LOCAL.
For details, see the FIFOFS(5FEA) man page.
FIFOFS API
The FIFOFS feature does not have its own API,
but enables nodes created using mkfifo() to be used as
pipes.
Network File System (NFS)
The Network File System (NFS) option provides transparent access to remote files on most UNIX (and many non-UNIX) platforms. For example, this facility can be used to load applications dynamically from the host to the target.
NFS_CLIENT
The NFS_CLIENT feature provides POSIX-compatible file I/O system calls on top
of the NFS file system. It provides only the client side
implementation of the protocol and thus requires a host system to provide
the server side implementation of the NFS protocol. The NFS_CLIENT feature can be configured to run on top of either
Ethernet or the point-to-point protocol (PPP). The NFS_CLIENT requires the POSIX_SOCKETS
feature to be configured.
The NFS protocol is supported over IPv4 or IPv6 and supports both NFSv2 and NFSv3 over the user datagram protocol (UDP) and transmission control protocol (TCP).
The NFS_CLIENT feature API is summarized in the following table. For general information on the API provided by this feature, see the POSIX standard (IEEE Std 1003.1b-1993). Note that some of the calls listed are also included in other features.
|
Function |
Description |
|---|---|
|
access() |
Check access permissions |
|
chdir, fchdir() |
Change current directory |
|
chflags() |
Modify file flags (BSD function) |
|
chmod, fchmod() |
Change access mode |
|
chown, fchown() |
Change owner |
|
chroot() |
Change root directory |
|
close() |
Close a file descriptor |
|
dup, dup2() |
Duplicate an open file descriptor |
|
fcntl() |
File control |
|
flock() |
Apply or remove an advisory lock on an open file |
|
fpathconf() |
Get configurable pathname variables |
|
fsync() |
Synchronize a file's in-core stats with those on disk |
|
getdents() |
Read directory entries |
|
getdirentries() |
Get directory entries in a file system independent format |
|
getfsstat() |
Get list of all mounted file systems |
|
ioctl() |
Device control |
|
link() |
Make a hard file link |
|
lseek() |
Move read/write file pointer |
|
mkdir() |
Make a directory file |
|
mkfifo() |
Make FIFOs |
|
mknod() |
Create a special file |
|
mount, umount() |
Mount or unmount a file system |
|
open() |
Open for reading or writing |
|
read, readv() |
Read from file |
|
readlink() |
Read a value of a symbolic link |
|
rename() |
Change the name of a file |
|
revoke() |
Invalidate all open file descriptors (BSD function) |
|
rmdir() |
Remove a directory file |
|
stat, fstat, lstat() |
Get file status |
|
statfs, fstatfs() |
Get file system statistics |
|
symlink() |
Make a symbolic link to a file |
|
sync() |
Synchronize disk block in-core status with that on disk |
|
truncate, ftruncate() |
Truncate a file |
|
umask() |
Set file creation mode mask |
|
unlink() |
Remove a directory entry |
|
utimes() |
Set file access and modification times |
|
write, writev() |
Write to a file |
The following library calls do not support multi-threaded applications:
|
Function |
Description |
|---|---|
|
opendir() |
Open a directory |
|
closedir() |
Close a directory |
|
readdir() |
Read directory entry |
|
rewinddir() |
Reset directory stream |
|
scandir() |
Scan a directory for matching entries |
|
seekdir() |
Set the position of the next readdir() call in the directory stream |
|
telldir() |
Return current location in directory stream |
For details, see NFS_CLIENT(5FEA).
NFS_SERVER
The NFS_SERVER
feature provides an NFS server on top of a local file system,
most commonly UFS, but possibly MSDOSFS.
It provides only the server side implementation of the protocol, the client
side being provided by the NFS_CLIENT feature. The NFS_SERVER requires the POSIX_SOCKETS
and UFS features.
The NFS protocol is supported over IPv4 and IPv6; it supports both NFSv2 and NFSv3 over UDP and TCP.
The NFS_SERVER feature API is summarized in the following table. For general information on the API provided by this feature, see the POSIX standard (IEEE Std 1003.1b-1993). Some of the calls listed are also included in other features.
|
Function |
Description |
|---|---|
|
getfh() |
Get file handle |
|
nfssvc() |
NFS services |
For details, see the NFS_SERVER(5FEA) man page.
MS-DOS File System (MSDOSFS)
The MSDOSFS
feature provides POSIX-compatible file I/O system calls on top of the MSDOSFS file system on a local disk. This feature requires a
local disk to be configured and accessible on the target system.
At least one of RAM_DISK or SCSI_DISK must be configured. It is usually embedded in any configuration
which uses a file system as part of the boot image of the system. MSDOSFS is frequently used with Flash memory.
The MSDOSFS feature supports long file names and file access tables (FATs) with 12, 16, or 32-bit entries.
For details, see MSDOSFS(5FEA).
MSDOSFS API
The MSDOSFS feature API is identical to the API exported by the NFS_CLIENT feature. However, some system calls in this API will return with error codes since the underlying file system layout does not allow support all of these operations; for example, symlink() and mknod(). For general information on the API provided by this feature, see the POSIX standard (IEEE Std 1003.1b-1993). Some of the calls listed are also included in other features.
FS_MAPPER
The FS_MAPPER feature provides support for swap in the system. It requires either the SCSI_DISK to be configured, as well as VIRTUAL_ADDRESS_SPACE. Swap is only supported on local disks. Swapping to a remote device or file over NFS is not supported. This feature uses a dedicated file system layout on disks.
The FS_MAPPER feature exports the swapon() system call.
For details, see the FS_MAPPER(5FEA) man page.
ISOFS
The ISOFS file system is used to access CD_ROM media.
PROCFS
The ChorusOS operating
system provides a /proc file system derived from
the FreeBSD 4.1 implementation of /proc. Due to major
differences in the implementation of the two systems, only a subset of the
FreeBSD /proc file system has been retained. However,
due to enhancements of the process model introduced by the ChorusOS operating
system, such as the support of multi-threaded processes, extensions have been
introduced to reflect the multi-threaded nature of the processes.
Such a file system is usually mounted, by convention, under the /proc directory. This directory is then populated and depopulated
dynamically and automatically depending on the life cycle of the processes.
ChorusOS actors are not reflected in this file system. Upon process creation
(using fork() or posix_spawn()) an entry
whose name is derived from the process identifier is created in the /proc directory. This per-process entry is in turn a directory
whose layout is almost identical from one process to another. Threads running
in this process are also represented by a regular file in the /proc file system (on a basis of one-to-one correspondence).
PROCFS API
The API supported by the PROCFS file system are similar to those exported by the UFS file system, although many of calls that do not have any significance when applied to a process will return with an error code. The list of entries that are supported below each process are listed in the following table.
|
Entry |
Description |
|---|---|
|
/proc |
Mount point |
|
/proc/curproc |
Symbolic link to the current process |
|
/proc/xxx |
Per-process directory (where xxx is the PID of the process) |
|
/proc/xxx/file |
Symbolic link to the executable file |
|
/proc/xxx/stats |
Per-process instrumentation |
|
/proc/xxx/status |
Process status information mostly used by ps(1) |
|
/proc/xxx/threads/ |
Process threads directory |
|
/proc/xxx/threads/tt |
Per-thread directory (where tt is the id of the thread) |
|
/proc/xxx/threads/tt/stats |
Per-thread instrumentation |
PDEVFS
The PDEVFS feature is a file system that has been specifically developed for ChorusOS. By convention, it is usually mounted in the /dev and /image directories. It enables an application to create device nodes without having an actual file system such as MSDOSFS, UFS or NFS available. All data structures are maintained in memory and have to be recreated upon each reboot.
It is also used internally by the ChorusOS operating system at system startup time. File types supported are:
-
Block/character devices
-
Directories
PDEVFS API
The PDEVFS API is the one exported by any file system, although most of the system calls will return with an error, since only a limited subset of operations are supported and meaningful. By default, the system mounts the PDEVFS file system as the root.
- © 2010, Oracle Corporation and/or its affiliates