File allocation table
adjective: an NT file system, originally a type of file system native to MS-DOS®; also, noun: the logical structure describing a disk partition for the FAT file system
A feature of the Windows NT operating system environment, which includes the end-user-visible Win32 Disk Administrator utility supported by a system-supplied NT intermediate driver, ftdisk, that handles disk partition mirroring, striping, and volume set management.
File control block
An internal NT file system structure in which a file system maintains state for an open file.
A user-mode-visible object that represents an open instance of a file, device, directory, volume, etc. A file object is accessed through the file handle returned by a protected subsystem’s function, which calls down to a system service that opens (or creates) a file object. Callers of the I/O system services can wait on a file handle.
At any given moment, several file objects can be associated with a single, shared data file, but each such file object has a unique handle and an object-specific value for the current file pointer.
A file object is sometimes called a “persistent object” because the entity that backs any runtime set of file objects is retained across system boots.
An intermediate driver that intercepts and processes I/O requests bound for an underlying device. Such a driver calls IoAttachDevice at initialization to alias its own device objects to those of the underlying device driver(s) or to each intermediate driver layered above an underlying device driver. See also device object and SFD.
a.k.a. “production” or “retail” system
A version of the system that has been compiled and built without symbols and support for debugging under-development components, making the free build smaller in size and faster than a checked build due to the lack of debugging symbols and checks. See also checked build.
File system
An FS is a file system driver that registers itself with the NT I/O Manager as an active file system. Unlike many other operating systems, NT does not have a particular must-be-resident file system, and several NT file systems can be active at the same time. NT file systems are dynamically located when a volume is mounted or when a remote name is being resolved: the I/O Manager calls the registered FSs in turn until one file system “recognizes” the volume structure or remote name.
Examples of NT-supplied file systems are FAT, NTFS, CDFS, the LAN Manager redirector, NPFS (named pipe file system), and RAW. See also IFS.
File system driver
The FSD refers to the portion of a driver that executes in the context of the caller, to which an I/O request is dispatched when the request is originally made. The FSD has no process virtual address space and no particular thread context because it operates in the context of whoever happens to call it.
An FSD also executes in the context of the lower-level (intermediate or mass-storage device) driver’s DPC routine when the I/O operation is being completed if the FSD indicated that it should be called upon completion of the IRP.
The term FSD normally refers to the device driver part of a file system driver when the driver also has an FSP associated with it; otherwise, it’s called simply a file system.
File system process
The FSP usually refers to a set of device-dedicated or system worker threads that aid a file system driver (FSD) in getting work done, but can also refer to a kernel-mode process set up by an FSD. FSP threads are generally used when a file system driver needs a thread context in which to work. An example is when the driver needs to be able to wait without tying up the calling thread. An FSP kernel-mode process is used only when an FSD must have a driver-specific process address space in which its device-dedicated threads execute. Most NT file system drivers conserve system memory and improve performance by not creating their own kernel-mode processes.
Communication between the FSD and the FSP threads is performed through the use of a communication region. This region is generally allocated in a device object’s device extension and consists of an interlocked queue and a synchronization event. See also device object, device extension, and event object.
Note that any NT driver (not just file systems) can create one or more device-dedicated threads, and a file system driver can use system worker threads. In particular, an NT driver should create a thread for I/O operations that use synchronization mechanisms (such as events, timers, semaphores, mutexes, etc.) other than spin locks. Such a driver’s thread can wait for an indefinite, nonzero interval on a Kernel-defined dispatcher object, but context switches to the thread slow down such a driver’s I/O operations.