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.