![]() In addition to the FSD components, both LANMan Redirector and LANMan Server include Windows services named Workstation and Server, respectively. The port/miniport model simplifies redirector development because the port driver, which all remote FSD miniport drivers share, handles many of the mundane details involved with interfacing a client-side remote FSD to the Windows I/O manager. Another redirector miniport driver is WebDAV (\Windows\ System32\Drivers\Mrxdav.sys), which implements the client side of file access over HTTP. The redirector is implemented as a port/miniport driver combination, where the port driver (\Windows\System32\Drivers\Rdbss.sys) is implemented as a driver subroutine library and the miniport (\Windows\System32\Drivers\Mrxsmb.sys) uses services implemented by the port driver. Windows includes a client-side remote FSD named LANMan Redirector (redirector) and a server-side remote FSD server named LANMan Server (\Windows\System32\Drivers\Srv.sys server). A server-side FSD listens for commands coming from a network connection and fulfills them by issuing I/O requests to the local FSD that manages the volume on which the file or directory that the command is intended for resides. The client FSD accepts I/O requests from applications and translates them into network file system protocol commands that the FSD sends across the network to a server-side component, which is typically a remote FSD. A client-side remote FSD allows applications to access remote files and directories. Remote FSDs consist of two components: a client and a server. The first time an application accesses the media after a dismount, the I/O manager reinitiates a volume mount operation for the media. A dismount occurs whenever an application requires raw access to the on-disk contents of a volume or the media associated with a volume is changed. ![]() Local FSDs also support file system dismount operations, which permit the system to disconnect the FSD from the volume object. Windows doesn't permit file data that is mapped by an application to be deleted either through truncation or file deletion. For example, they must query the memory manager whenever an application attempts to truncate a file in order to verify that no processes have mapped the part of the file beyond the truncation point. They also integrate with the memory manager so that mapped files are implemented correctly. To improve performance, local FSDs usually use the cache manager to cache file system data, including metadata. (See Chapter 10 for more information on VPBs.) ![]() The VPB's connection results in the I/O manager redirecting I/O requests targeted at the volume device object to the FSD device object. The I/O manager makes a connection through the volume parameter block (VPB) between the volume's device object (which is created by a storage device) and the device object that the FSD created. When a local FSD recognizes a volume, it creates a device object that represents the mounted file system format. A boot sector contains enough information so that a local FSD can both identify the volume on which the sector resides as containing a format that the FSD manages and locate any other metadata necessary to identify where metadata is stored on the volume. The first sector of every Windows-supported file system format is reserved as the volume's boot sector. Volume recognition involves an examination of a volume's boot sector and often, as a consistency check, the file system metadata. Once the FSD is registered, the I/O manager can call on it to perform volume recognition when applications or the system initially access the volumes. As we described in the section "Volume Mounting" in Chapter 10, a local FSD is responsible for registering with the I/O manager. Figure 12-5 shows a simplified view of how local FSDs interact with the I/O manager and storage device drivers. Local FSDs include Ntfs.sys, Fastfat.sys, Udfs.sys, Cdfs.sys, and the Raw FSD (integrated in Ntoskrnl.exe). Network FSDs allow users to access data volumes connected to remote computers. Local FSDs manage volumes directly connected to the computer. Windows has two different types of file system drivers: (See Chapter 1 for more information on the DDK, and see \whdc\devtools\ifskit for more information on the IFS Kit.) Whereas you need the Windows DDK in order to build standard kernel-mode drivers, you must have the Windows Installable File System (IFS) Kit to build file system drivers. Thus, they use a superset of the exported Ntoskrnl functions that standard drivers use. For enhanced performance, file system drivers also usually rely on the services of the cache manager. Perhaps most significant, they must register as an FSD with the I/O manager and they interact more extensively with the memory manager. Although FSDs run in kernel mode, they differ in a number of ways from standard kernel-mode drivers. File system drivers (FSDs) manage file system formats.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |