BasicVfsConcepts [FreeBSD WIKI]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
The following descriptions are rather high-level and (over-)simplified.

  * **vnode**. \\  A structure representing a filesystem entity like a file, directory, device node, etc at VFS abstraction level. A vnode doesn't contain any filesystem specific data, but main contain a handle of (pointer to) such data. \\ //A vnode pointer variable is usually named vp.//
  * **Physical block number**. \\  In the context of %%FreeBSD%% filesystems layer we use this term when referring to fixed-size 512-byte blocks. Many kernel functions operate on data in terms of these 512-byte blocks. These blocks are used when describing data on media underneath filesystem level (disks, partitions, slices, etc). \\  Note that the underlying media may have its own notion of a block and block size. A different term should be used to refer to media blocks: e.g. sectors, media blocks, etc. %%FreeBSD%% filesystem and buffer cache layers are agnostic of these blocks. Individual filesystem drivers may have to (or want to) take them into account. \\ //Physical block number is frequently named bn.//
  * **Logical block number**. \\  Typical filesystems have a notion of filesystem blocks which may be constituted of multiple physical (512-byte) or media blocks. Filesystem entities are thought to be composed of logical blocks. The logical blocks of a single entity (file, directory) are not necessarily contiguous on underlying media. The underlying blocks belonging to the same logical block must be contiguous on media. Logical block number points to a particular logical block within the filesystem entity. \\ //Logical block number is frequently named lbn.//
  * **Device vnode**. \\  A filesystem is backed by some media that actually contains the data. \\  Device vnode refers to a vnode of the device filesystem (devfs) associated with a device representing the underlying media for the filesystem. \\ //Device vnode is oftenly referred to as devvp.//
  * **Buffer cache**. \\  Buffer cache is a layer between filesystems and I/O code that performs actual media access via peripheral drivers. Buffer cache maintain a cache of accessed data on a vnode+lbn basis. If a vnode has an associated VM object (which it typically does) then buffer cache uses pages from the VM object to hold cached data. Thus a buffer cache and VM page cache cooperation is achieved.
  * **struct bufobj**. \\  struct bufobj represents a set of buffers belonging to the same abstract object, typically a vnode, where different buffers cover different non-overlapping ranges of data within the object. This structure has bo_ops member of type struct buf_ops that provides methods to be used for I/O on the buffers belonging to the bufobj. \\  //struct bufobj pointers are conventionally named bo.//
  * **struct buf**. \\  struct buf represents a single buffer. In addition to holding identity of the buffer (vnode/bufobj, physical and logical block numbers and offsets, size) this structure is used to describe both a current state of the buffer and an I/O operation to be performed on the buffer. \\ //struct buf pointers are conventionally named bp.//
  * **bread(9) family of functions**. //(actually not documented in manual pages)// \\  Filesystem use bread (breadn, breada, etc) functions to access underlying data through a buffer cache layer. The functions take a vnode and a logical block number in terms of that vnode as parameters that identify the data to be read. The read data is returned via a pointer to struct buf that represents the data. Typically, to access a filesystem entity the filesystem uses its own vnode representing that entity and a logical block number calculated in terms of filesystem's own logical block size. A filesystem may have some internal/private on-disk data/metadata that is not considered as a filesystem entity (e.g. superblock). To access such data a filesystem has to use a device vnode associated with a device representing the underlying media. In this case the block number has to be calculated according to the rules of the device vnode.
  * **VOP_BMAP**. \\  VOP_BMAP translates a given logical block number within a given vnode to a physical (512-byte) block number within underlying media. It can also provide additional information like a number of additional //logical// blocks that are sequentially laid out on the media following the inquired block.
  * **VOP_STRATEGY**. \\  VOP_STRATEGY method fulfills an I/O request described by given struct buf object. The method should expect both that the buf already has correct/translated physical block number ''%%b_blkno%%'' or that only logical block number is correct. In the latter case ''%%b_blkno == b_lblkno%%''. In that case the method should perform translation on its own, similarly to how VOP_BMAP does that. In the end the strategy method should set ''%%b_iooffset%%'' from''%% b_blkno%%'' as this is what is actually used by I/O lower levels (as opposed to block numbers). Finally the actual I/O has to be performed. This may be done using''%% BO_STRATEGY%%'' method of ''%%bufobj%%'' associated with ''%%devvp%%''.

----

{{tag>Stale}}