Windows NT File Systems
The File Systems Supported By Windows NT
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.
Depending on who you talk to you will get different answers to the question "How many file systems does Windows NT support?" The Microsoft Windows NT resource kit lists only two file systems File Allocation Table (FAT) and Windows NT File System (NTFS). Most of the training material for Microsoft lists these two plus the CDROM File System (CDFS).
According to the Microsoft website examples of NT-supplied file systems are FAT, NTFS, CDFS, the LAN Manager redirector, NPFS (named pipe file system), and RAW. Examples listed in other places include the MAC file system (on NT servers) and a new OLE file system is also under development.
Previous versions of Microsoft Windows NT Server came with native support for HPFS. HPFS was introduced in 1990 as part of OS/2 Version 1.2. Microsoft Windows NT Server 4.0 does not officially support HPFS. The HPFS driver that shipped with older versions of NT server can be loaded onto an NT 4.0 server. This process happens automatically if you upgrade an old NT server with the the HPFS driver installed.
NT does not support the FAT32 file system available on Windows 95.
The following table contains the partition and file size limitations of the various file system formats under Windows NT:
|File System||Max. Partition Size||Max. File Size|
|FAT||4 gigabytes||4 gigabytes|
|HPFS||2,048 gigabytes||4 gigabytes|
|NTFS||16 exabytes||16 exabytes|
The FAT file system for personal computers was designed at a time that floppy diskettes were the most used media, and hard drives had a capacity of ten megabytes on the average. Because of this, FAT was not designed with larger capacities in mind, and has since required the use of new operating systems and system BIOS's to allow for the use of larger hard drives and directory trees of files that number in the thousands or millions. Partitions formatted with FAT are broken into clusters. The FAT file system is also prone to fragmentation, which is the result of data being written to noncontiguous clusters, which can slow down the read/write process. FAT writes files to the first available cluster it can find, and then skips ahead past used clusters to complete writing a file. These clusters are broken down into sectors. FAT also keeps track of a few attributes for each file, such as the name of the file, the address of the starting sector, whether the file was deemed a system file, a read-only attribute, an archive bit (denoting if the file had been backed up or changed since the last time it was backup up), and a date for the file's creation or the last time the file was modified.
Because the overhead of using the FAT file system grows as partition size increases, it is advisable to not use FAT on partitions that are greater than 200 megabytes.
Whenever Windows NT formats a floppy disk, it will format using FAT because the overhead of the NTFS file system would create too much extraneous, although important, information making the actual capacity of the floppy disk too small. Therefore, NTFS is not a supported format on floppy disks.
FAT is handled slightly differently under NT. While NT's FAT implementation is one hundred percent backward compatible, NT also adds features to the FAT file system. Long filenames are allowed for FAT partitions, and are handled the same way as long filenames on a Windows 95 system. That is, the generated 8.3 filename is stored along with the long filename.
As discussed earlier, some programs are incompatible with the NT architecture. The most common causes for this incompatiblity are trying to directly access the hardware or running into problems with the NTFS. An example of this would be Partition Magic.
Any FAT partitions that unders go a transformation as a result of a DOS like utility or program, for example Stacker or DriveSpace, will not be readable by Windows NT
NTFS is the preferred file system for Windows NT because it allows for the use of all NT's security features. A system, however, can use all three of the available file systems at the same time. Of course, only the NTFS partitions will have the advantages.
NTFS represents an evolution from the HPFS file system used by OS/2. (Remember that the entire NT operating systems was to represent an evolution from OS/2.) A major part of the security model that NT offers is based on the NTFS file system. While shared directories can be set up on an NT server regardless of the file system used, it is only with NTFS that individual files can be assigned permissions. These rights, which also includes rights to a directory, can be assigned permissions whether or not they are shared. Every attribute of the NTFS is kept as a file.
File descriptions on an NTFS volume are stored in a master file table (MFT), which is also a file. Besides the several records that contain data about the MFT itself, the MFT contains a record for each file and directory, and a log file. A mirror of the MFT is also kept, as well as pointers to the MFT and its mirror, which are stored in the boot sector of the disk. A copy of the boot sector is stored in the logical center of the disk. With this many copies of the MFT, data recovery becomes even easier. That is why NTFS is known as a "recoverable file system.
When a partition is formatted as NTFS, numerous system files are created that keep track of certain attributes of that partition.
The NTFS filesystem supports filenames of up to 255 characters. (Files created from the command line can only have filenames up to 253 characters.)
Any long filenames that exist on the FAT partition will be seen with the standard 8.3 filename limitation. NT creates an 8.3 filename along with it's long filenames the same way that Windows 95 creates 8.3 filenames along with long filenames.
Of course, the main purpose of file systems are to keep track of data stored on hard drives and to facilitate the reading and writing of this data. NTFS's recoverable file system is a great enhancement on FAT's careful-write file system and the lazy-write file system used by UNIX and FAT as implemented on Windows NT.
FAT's careful-write file system allows writes one at a time and alters its volume information after each write. This is a very secure form of writing. It is, however, also a very slow process.
The lazy-write file system uses a cache. All writes are performed to this cache and the file system intelligently waits for the appropriate time to perform all the writes to disk. This system gives the user faster access to the file system and prevents holdups due to slower disk access. It is also possible that if the same file is being modified more than once that it may never actually be written to disk until the modifications are finished within the cache. Of course, this can also lead to lost data if the system crashes and unwritten modifications are still held in the cache.
NTFS's recoverable file system provides the speed of a lazy-write file system along with recovery features. The recovery features come from a transaction log that keeps track of which writes to disk have been completed and which ones have not. In the recovery process this log can assure that after only a few moments after a reboot that the file system's integrity is back to one hundred percent without the need of running a utility such as CHKDSK, which requires the scanning of an entire volume. The overhead associated with this recoverable file system is less than the type used by the careful-write file system.
The recoverable file system can also ensure that an NTFS partition will always remain accessible, even if the partition is bootable and the bootstrap has been damaged. In this instance, you can boot from another drive, or boot from disks, and still have access to the formerly-bootable volume.
NTFS supports hot-fixing as well. Instead of FAT's notorious Abort, Retry, Fail? message, NTFS will attempt to move the data in a damaged cluster to a new location in a fashion that is transparent to the user. The damaged cluster is then marked as unusable. Unfortunately, it is possible that the moved data will be unusable anyhow, because the chance of corruption is very likely unless fault tolerance is enabled, and then the replicated data from the nondamaged cluster will be used in its place.
The way that NTFS processes file actions as transactions is the key to its high degree of recoverability. Each write request to an NTFS partition generates redo and undo information. The redo information tells NTFS how to recreate the intended write. The undo information tells NTFS how to rollback the transaction the event the transaction is incomplete or has an error. Once the write transaction is complete, NTFS generates a file update commit. Otherwise, NTFS uses the undo information in order to rollback the request.
The type of commit that NTFS performs is called a lazy commit. This is similar to a lazy write in the sense that it will cache these file commits and write them to the transaction log when system resources are high. This feature allows NTFS's high reliability features to have less overhead, overall, on the system.
In the case of system crash or unexpected shutdown of NT (such as someone accidentally powering off the server before a clean shutdown is performed), NTFS will perform a three pass system check upon restarting.
As with most transactional-type logs, checkpoints are created once all log transactions since the last checkpoint have been confirmed. Checkpoint creation occurs every few seconds. The first pass that NTFS makes after a system restart is called the analysis pass. In this pass, NTFS compares items in the transaction log, since the last checkpoint, to the clusters those transactions dealt with. A second pass, called the redo pass, performs all the transaction steps since the last checkpoint. The third pass, which is the undo pass, performs a rollback on any incomplete transactions.
Whenever you start Windows NT, the NTFS volumes are checked to see whether they are "dirty." If it detects a potential problem, Windows NT will automatically run CHKDSK /F.
If the CHKDSK utility finds orphaned files or directories, they are moved to special directories which are named FOUNDnnn (if no other FOUNDnnn directories exist, the first one created will be FOUND000, the next is FOUND001, and so on). Directories are named DIRnnn.CHK, and if they have files associated with them, those files will be placed within that directory. Orphaned files are named FILEnnn.CHK.
If you want to run CHKDSK /F from the command line, run it from a drive other than the one you are checking. For example, to check the C: drive, from a D: prompt run CHKDSK C: /F. If you CHKDSK cannot get control of the drive because it is in use, it will ask you if it should run automatically the next time NT is booted.
Space-saving benefits of NTFS
Under the FAT file system, the smallest amount of disk space a file can use is based on the size of a cluster, not the size of the file. Typically, clusters on FAT-formatted hard disks consist of 2,048 bytes. However, on today's popular large disks (larger than 1.5GB), clusters range in size from 4,096 bytes on a 250MB hard disk to as large as 32,738 bytes on a 1.7GB hard disk.
This means that storing a 50-byte AUTOEXEC.BAT file on a 1.7GB hard disk actually requires a whole cluster, or 32,768 bytes. In other words, there's a waste of 32,718 bytes! On a 512MB hard disk formatted with the NTFS file system, a cluster consists of only 512 bytes. On hard disks that range in size from 512MB to 1GB, the cluster size moves up to 1,024 bytes. From 1GB to 2GB, the cluster size doubles to 2,048 bytes. From 2GB on up, the cluster size has a maximum of 4,096 bytes. Therefore, the NTFS file system makes the most efficient use of the available hard disk space.
To store the same 50-byte AUTOEXEC.BAT file on a 1.7GB hard disk formatted with the NTFS file system would require only 2,048 bytes: a savings of 30,720 bytes compared to the FAT file system. In the speed department, accessing sequential access files over 512MB is significantly faster than on a FAT-formatted hard disk. Access to all random access files is faster as well.
Available only to the NTFS file system on Windows NT is file-level compression. This form of compression is unlike the more familiar DOS-based programs, such as Stacker or DriveSpace.
These DOS device driver-based programs create one large file that contains all the files contained in the drive that you compressed. This single file is a mountable volume that a DOS device driver mounts as its own drive. This drive is then viewed as a standard DOS FAT volume.
Windows NT uses Explorer and the COMPACT.EXE utility to individually compress files. These compressed files are then decompressed in real time when the files are opened.
Windows NT's type of compression is much safer than the DOS method, as it is possible that a corrupted compressed volume on DOS could result in loss of the entire volume. As with all file compression techniques, there is a certain amount of overhead for the decompression and recompression of these files.
With Windows NT's compression scheme, each file is handled separately. Therefore, any corruption will only affect that one file.
The CONVERT.EXE utility is a command-line utility that can convert HPFS and FAT partitions over to NTFS. It will not convert from NTFS, nor will it allow for the conversion of FAT to HPFS or vice versa.
The proper syntax for the CONVERT.EXE utility is CONVERT d: /fs:ntfs where d is the drive letter for the partition you are converting. You cannot convert the boot partition while it is active, so if the CONVERT command is attempted on the boot partition, an entry is written to the Registry that will initiate the conversion the next time the system is booted.
Because RISC-processor-based machines require FAT on the boot partition, never run the CONVERT.EXE utility on these. If you do, the machine will no longer be bootable.