Byte File System (BFS) Repository Services

The Byte File System (or BFS) is a CMS file system that has the following characteristics:
  • Files contain streams of bytes. Nevertheless, data is managed by the file pool in units of 4K bytes (data blocks).
  • Files are associated with hierarchical directories
  • File spaces (file systems) or portions thereof can be mounted to extend the current path address to objects for a user.
  • For each file space there is a single top (root) directory which has a name that corresponds to the name of that file space. This name is not necessarily associated with a user virtual machine and has no association with authority to connect to the file pool.
  • Files consume storage blocks assigned to a file space in proportion to the size of the file. Space (a limit of so many storage blocks) is assigned to a file space by the file pool administrator. When this space is depleted, no more files can be created in the file space unless space is freed or more space is assigned. For BFS file spaces, there is no capability for consumption of space beyond the file space capacity. That is, you cannot consume blocks in excess of the file space limit temporarily before commit (as you can in SFS).
  • Objects are shared with other users based on permission bits and owner UID (user ID) and GID (group ID) that are associated with the object. These are compared to the UID and GID of the file accessor. The permission bits allow for read, write, or execute at the individual user level, group level, or world (public) level.
  • File system users can be local or remote (accessed with a network).
  • Although atomicity of file system requests is enforced, multiple SFS requests are not considered grouped in logical units of work for purposes of controlling commit points or rolling back (undoing) requests to the file system. The guarantees for atomicity means user or application functions for BFS either complete or fail as a unit. This atomicity is accomplished through a combination of serializations in the CMS user machines where a request originates and the use of logical units of work in the file pool server, where applicable. The file pool server treats each BFS request to the repository server as a logical unit of work. More than one server request may be required to satisfy a single (atomic) operation against a BFS file. BFS requests are not associated with CMS work units.
  • Coordinated Resource Recovery does not apply.
  • DFSMS/VM provides storage management functions. It erases expired files and migrates low activity files to auxiliary storage which enables better utilization of high performance DASD. See z/VM: DFSMS/VM Planning Guide for more information.
  • Object naming is through POSIX standard path naming or fully qualified names, based on a VMBFS identifier (constant that indicates BFS type file space), the file pool name, the file space name, and the hierarchy of directories down to the object itself. Object names have a length limitation of 256 bytes and path names are limited to 1024 bytes.
  • In addition to files and directories, various special object types are allowed according to the POSIX standard. Examples are FIFOs, hard links, symbolic links, and external links. These allow for inter-process communications, extensions to the scope of addressing, and even extensions to the types of objects.
  • BFS allows concurrent reads and writes and does not have open-to-close consistency for file changes. However, concurrent writes must wait for completion of any read or write operations that have already started. That is, the concurrency respects atomicity rules previously described.
  • Normal data consistency rules control when you see data repository changes made by other users. In BFS you see changes as soon as an atomic request completes. That is, you do not see a change in progress, but you see the change as soon as it completes. There is no grouping of change requests (file updates) into transactions or logical units of work.
  • You can lock byte ranges in files to synchronize access with other users. You can lock against reads and writes to the files, or just against writes. This locking is voluntary. That is, participation is by convention between users or applications. Locking is only enforced when it is used, and, even then it does not restrict data access.