extented partion

When I first installed Linux, I was wondering why the file system in Linux is different from the file system in Windows? I used to know the file system FAT 16, FAT 32 and NTFS, Linux Ext2 file system I found, Ext3, and Ext4. What is the difference of format the file system? I will explain a little earlier than the file system functions.

File system is a system designed to save the file on a data storage device, be it on your computer (hard drive) or device outside the computer (flash, external hard drive, etc.), each has a certain capacity storage media that can be read by any operating system . such as FAT 16, FAT 32 and NTFS file system that is in Windows, Ext2, Ext3, and Ext4 on Linux, and Mac OS HFS at.

On this subject I will discuss the file system on Linux, the Linux file system using the Ext / Extended, which is divided into three, namely Ext2, Ext3, and Ext4, each of which is a refinement of the previous system file:

A. Ext2 - Second Extended File System 2

Description and Objectives:

Ext2 was first developed and integrated in the Linux kernel, and is now also being developed for use on other operating systems.

The goal is to create a powerful file system, which can implement those files from UNIX semantics, and has an advanced service features.

Abilities:

• Ext2 file system capable of supporting multiple file types from UNIX standard, such as regular files, directories, device special files and symbolic links.
• Ext2 able to manage system files are created in a large partition.
• Ext2 file system capable of generating file names are long. Maximum of 255 characters.
• Ext2 require several blocks to super user (root).

2. Ext3 - Third Extended File System

Description and Objectives:

Ext3 is a journalled file system, journalled file system designed to help protect data in it. With a journalled filesystem, then we no longer need to check the consistency of data, which will take very long for my disk.

Ext3 is a filesystem that was developed for use on the Linux operating system. Ext3 is the result of improvement of Ext2 Ext2 into better shape by adding a variety of advantages.

Pros:

• Ext3 does not support the process of checking the file system, even when the system is not cleaned experiencing "shutdown", except in some very rare hardware errors.
• Things like this happen because the data is written or stored into a disk in a way so that the file system is always consistent.
• The time required to recover EXT3 file system after the system is not cleaned off
• Is independent of the size of the file system or file number, but depends on the size of the "journal" used to maintain consistency. Journal of the size of the initial (default)
• Requires about 1 second to recover (depending on the speed of hardware).

Ext2 and Ext3 comparison:

• In general, the principles of the Ext2 with Ext3.
• Method of accessing files, data security, and the use of disk space between the file system is almost the same.
• The fundamental difference between the two file systems is the concept of journaling file system that is used in Ext3.
• This led to the concept of journaling Ext2 and Ext3 have differences in terms of durability and data recovery from damage.
• This causes the Ext3 journaling concept is much faster than Ext2 in data recovery from damage.

3. Ext4 - Fourth Extended File System

Description and Purpose

Ext4 was released as a complete and stable starting from kernel 2.6.28 so if your distro has a default kernel version tersebuat or on its automated system you already support Ext4 (with records already in the include into the kernel) but it must use the version of e2fsprogs version 1:41 .5 or more.

Pros:

• Has been declared stable and supported since Linux 2.6.28 kernel.
• Designed to provide better performance and increased capabilities.
• Can increase the maximum capacity of the filesystem to 1 EXA Byte (1,048,576 Tera Byte), with a maximum size of the filesystem to 16 TB to its maximum file size, Fast fsck, Journal checksumming, Defragmentation support.
• Reduce the time needed to check the hard drive (which fsck on Ext3 filesystem, every 2030 times the mount).
• Based on benchmark tests conducted by several benchmarker, Ext4 Filesystem has a significant performance advantage in the writing and reading large files.
• Ext4 Filesystem set aside another filesystem like xfs, jfs, Reiserfs and Ext3. In the case of Ubuntu 9.04, ext4 filesystem on the suspect to be the main factor that accelerates the Ubuntu 9.04 boot time. Ext4 Filesystem also increase longevity of flash media such as SSD. Due to Ext4 filesystem do not write the ext3 Filesystem data as written several times.

initial FAT16

In 1984, IBM released the PC AT, which featured a 20 MB hard disk. Microsoft introduced MS-DOS 3.0 in parallel. Cluster addresses were increased to 16-bit, allowing for up to 65,524 clusters per volume, and consequently much greater file system sizes, at least in theory. However, the maximum possible number of sectors and the maximum (partition, rather than disk) size of 32 MB did not change. Therefore, although cluster addresses were 16 bits, this format was not what today is commonly understood as FAT16. A partition type 0x04 indicates this form of FAT16 with less than 65536 sectors (less than 32 MB for sector size 512).

With the initial implementation of FAT16 not actually providing for larger partition sizes than FAT12, the early benefit of FAT16 was to enable the use of smaller clusters, making disk usage more efficient, particularly for files several hundred bytes in size, which were far more common at the time.

MS-DOS 2.x hard disks larger than 15 MB are incompatible with later versions of MS-DOS.A 20 MB hard disk formatted under MS-DOS 3.0 was not accessible by the older MS-DOS 2.0 because MS-DOS 2.0 did not support version 3.0's FAT16. MS-DOS 3.0 could still access MS-DOS 2.0 style 8 KB-cluster partitions under 15 MB.

Final FAT16

Finally in November 1987, Compaq MS-DOS 3.31 (a modified OEM version of MS-DOS 3.3 released by Compaq with their machines) introduced what today is simply known as the FAT16 format, with the expansion of the 16-bit disk sector count to 32 bits in the BPB. Although the on-disk changes were minor, the entire DOS disk driver had to be converted to use 32-bit sector numbers, a task complicated by the fact that it was written in 16-bit assembly language. The result was initially called the DOS 3.31 Large File System. Microsoft's DSKPROBE tool refers to type 0x06 as BigFAT, whereas some older versions of FDISK described it as BIGDOS. It is also known as FAT16B.

Since older versions of DOS could not cope with more than 65535 sectors, it was also necessary to introduce a new partition type for this format in order to hide it from pre-DOS 3.31 issues of DOS. While the original form of FAT16 with less than 65536 sectors had a partition type 0x04, a type 0x06 indicates 65536 or more sectors. In addition to this changed partition ID and the expansion of the disk drivers format to cope with more than 65535, the only other difference between the original FAT16 and the FAT16B format is the usage of the newer BPB with 32-bit sector entry, so that newer operating systems can cope also with the original FAT16 format without any necessary changes. If partitions to be used by pre-DOS 3.31 issues of DOS need to be created by modern tools, the only criteria theoretically necessary to meet are a sector count of less than 65536 and the usage of the old partition ID. In practice, however, type 0x01 and 0x04 partitions should not be physically located outside the first 32 MB of the disk due to other restrictions in MS-DOS 2.x, which could not cope with them otherwise.

In 1988, the FAT16B improvement became more generally available through DR DOS 3.31, MS-DOS 4.0 and OS/2 1.1. The limit on partition size was dictated by the 8-bit signed count of sectors per cluster, which originally had a maximum power-of-two value of 64. With the standard hard disk sector size of 512 bytes, this gives a maximum of 32 KB cluster size, thereby fixing the "definitive" limit for the FAT16 partition size at 2 GB for sector size 512. On magneto-optical media, which can have 1 or 2 KB sectors instead of 0.5 KB, this size limit is proportionally larger.

Much later, Windows NT increased the maximum cluster size to 64 KB by considering the sectors-per-cluster count as unsigned. However, the resulting format was not compatible with any other FAT implementation of the time, and it generated greater internal fragmentation. Windows 98, SE and ME also supported reading and writing this variant, but its disk utilities did not work with it and some FCB services are not available for such volumes. This contributes to a confusing compatibility situation.

Prior to 1995 versions of DOS accessed the disk via CHS addressing only. When MS-DOS 7.0 / Windows 95 introduced LBA disk access, partitions could start being physically located outside the first ca. 8 GB of this disk and thereby out of the reach of the traditional CHS addressing scheme. Partitions partially or fully located beyond the CHS barrier therefore had to be hidden from non-LBA-enabled operating systems by using the new partion type 0x0E in the partition table instead. FAT16 partitions using this partition type are also named FAT16X. The only difference compared to previous FAT16 partitions is the fact that some CHS-related geometry entries in the BPB record, namely the number of sectors per track and the number of heads, may contain no or misleading values and should not be used.

The number of root directory entries available for FAT12 and FAT16 is determined when the volume is formatted, and is stored in a 16-bit field. For a given number RDE and sector size SS the number RDS of root directory sectors is RDS=ceil((RDE×32)/SS), and RDE is normally chosen to fill these sectors, i.e., RDE*32=RDS*SS. FAT12 and FAT16 media typically use 512 root directory entries on non-floppy media. Some third-party tools like mkdosfs allow the user to set this parameter.

FAT32

In order to overcome the size limit of FAT16, while at the same time allowing DOS real mode code to handle the format, and without reducing available conventional memory unnecessarily, Microsoft expanded the cluster size yet again, calling the new revision FAT32. Cluster values are represented by 32-bit numbers, of which 28 bits are used to hold the cluster number. The boot sector uses a 32-bit field for the sector count, limiting the FAT32 volume size to 2 TB for sector size of 512 bytes and 16 TB for sector size of 4,096 bytes.

 FAT32 was introduced with MS-DOS 7.1 / Windows 95 OSR2 in 1996, although reformatting was needed to use it, and DriveSpace 3 (the version that came with Windows 95 OSR2 and Windows 98) never supported it. Windows 98 introduced a utility to convert existing hard disks from FAT16 to FAT32 without loss of data. In the Windows NT line, native support for FAT32 arrived in Windows 2000. A free FAT32 driver for Windows NT 4.0 was available from Winternals, a company later acquired by Microsoft. Since the acquisition the driver is no longer officially available. Since 1998, Caldera's dynamically loadable DRFAT32 driver could be used to enable FAT32 support in DR-DOS. The first version of DR-DOS to natively support FAT32 and LBA access was OEM DR-DOS 7.04 in 1999. That same year IMS introduced native FAT32 support with REAL/32 7.90, and IBM 4690 OS added FAT32 support with version 2.Ahead Software provided another dynamically loadable FAT32.EXE driver for DR-DOS 7.03 with Nero Burning ROM in 2004. IBM PC DOS introduced native FAT32 support with OEM PC DOS 7.10 in 2003.

The maximum possible size for a file on a FAT32 volume is 4 GB minus 1 byte or 4,294,967,295 (2³²−1) bytes. This limit is a consequence of the file length entry in the directory table and would also affect huge FAT16 partitions with a sufficient sector size. Video applications, large databases, and some other software easily exceed this limit.

The open FAT+ 

specification proposes how to store larger files up to 256 GB minus 1 byte or 274,877,906,943 (2³⁸−1) bytes on slightly modified and otherwise backwards compatible FAT32 volumes, but imposes a risk that disk tools or FAT32 implementations not aware of this extension may truncate or delete files exceeding the normal FAT32 file size limit. Also, support for FAT32+ (and FAT16+) is limited to some versions of DR-DOS and FreeDOS and not available in mainstream operating systems so far. (This extension is critically incompatible with the /EAS option of the FAT32.IFS method to store OS/2 extended attributes on FAT32 volumes.)

As with previous file systems, the design of the FAT32 file system does not include direct built-in support for long filenames, but FAT32 volumes can optionally hold VFAT long filenames in addition to short filenames in exactly the same way as VFAT long filenames have been optionally implemented for FAT12 and FAT16 volumes.

Two partition types have been reserved for FAT32 partitions, 0x0B and 0x0C. The latter type is also named FAT32X in order to indicate usage of LBA disk access instead of CHS. On such partitions, some CHS-related geometry entries in the EBPB record, namely the number of sectors per track and the number of heads, may contain no or misleading values and should not be used.

A free Windows-based FAT32 formatter is available that overcomes many of the arbitrary limitations imposed by Microsoft.

NTFS

NTFS (New Technology File System) is the standard file system of Windows NT, including Windows 2000, Windows XP, and all their successors to date.

NTFS supersedes the FAT file system as the preferred file system for Microsoft’s Windows operating systems. NTFS has several improvements over FAT and HPFS (High Performance File System) such as improved support for metadata and the use of advanced data structures to improve performance, reliability, and disk space utilization, plus additional extensions such as security access control lists (ACL) and file system journaling.

NTFS Log

NTFS is a Journaling file system and uses the NTFS Log ($LogFile) to record metadata changes to the volume.

It is a critical functionality of NTFS (a feature that FAT/FAT32 does not provide) for ensuring that its internal complex data structures (notably the volume allocation bitmap), or data moves performed by the defragmentation API, the modifications to MFT records (such as moves of some variable-length attributes stored in MFT records and attribute lists), and indices (for directories and security descriptors) will remain consistent in case of system crashes, and allow easy rollback of uncommitted changes to these critical data structures when the volume is remounted.

USN Journal

The USN Journal (Update Sequence Number Journal) is a system management feature that records changes to all files, streams and directories on the volume, as well as their various attributes and security settings. The journal is made available for applications to track changes to the volume. This journal can be enabled or disabled on non-system volumes and is not enabled by default for a newly added drive.

Hard links and short filenames

Originally included to support the POSIX subsystem in Windows NT, hard links are similar to directory junctions, but used for files instead of directories. Hard links can only be applied to files on the same volume since an additional filename record is added to the file's MFT record. Short (8.3) filenames are also implemented as additional filename records and directory entries that are linked and updated together. Hard links also have the behavior that changing the size or attributes of a file may not update the directory entries of other links until they are opened.

Alternate data streams (ADS)

Alternate data streams allow more than one data stream to be associated with a filename, using the filename format "filename:streamname" (e.g., "text.txt:extrastream"). Alternate streams are not listed in Windows Explorer, and their size is not included in the file's size. Only the main stream of a file is preserved when it is copied to a FAT-formatted USB drive, attached to an e-mail, or uploaded to a website. As a result, using alternate streams for critical data may cause problems. NTFS Streams were introduced in Windows NT 3.1, to enable Services for Macintosh (SFM) to store Macintosh resource forks. Although current versions of Windows Server no longer include SFM, third-party Apple Filing Protocol (AFP) products (such as Group Logic's ExtremeZ-IP) still use this feature of the file system.

Malware has used alternate data streams to hide its code; some malware scanners and other special tools now check for data in alternate streams. Microsoft provides a tool called Streams to allow users to view streams on a selected volume.

Very small ADS are also added within Internet Explorer (and now also other browsers) to mark files that have been downloaded from external sites: they may be unsafe to run locally and the local shell will require confirmation from the user before opening them. When the user indicates that he no longer wants this confirmation dialog, this ADS is simply dropped from the MFT entry for downloaded files.

Some media players have also tried to use ADS to store custom metadata to media files, in order to organize the collections, without modifying the effective data content of the media files themselves (using embedded tags when they are supported by the media file formats such as MPEG and OGG containers); these metadata may be displayed in the Windows Explorer as extra information columns, with the help of a registered Windows Shell extension that can parse them, but most media players prefer to use their own separate database instead of ADS for storing these information (notably because ADS are visible to all users of these files, instead of being managed with distinct per-user security settings and having their values defined according to user preferences).

Sparse files

A sparse file: The empty bytes don't need to be saved, thus they can be represented by metadata.

Sparse files are files with segments stored at different file offsets with no actual storage space used for the space between segments. When a file is read back, the file system driver returns zeros for any data that does not actually exist, so the file may appear to be mostly filled with zeros.

Database applications, for instance, sometimes use sparse files. Because of this, Microsoft has implemented support for efficient storage of sparse files by allowing an application to specify regions of empty (zero) data. An application that reads a sparse file reads it in the normal manner with the file system calculating what data should be returned based upon the file offset. As with compressed files, the actual sizes of sparse files are not taken into account when determining quota limits.

File compression

NTFS can compress files using LZNT1 algorithm (a variant of the LZ77 ). Files are compressed in 16-cluster chunks. With 4kB clusters, files are compressed in 64kB chunks. If the compression reduces 64kB of data to 60kB or less, NTFS treats the unneeded 4kB pages like empty sparse file clusters – they are not written. This allows not unreasonable random-access times. However, large compressible files become highly fragmented as then every 64k chunk becomes a smaller fragment. Compression is not recommended by Microsoft for files exceeding 30MB because of the performance hit.

The best use of compression is for files which are repetitive, written seldom, usually accessed sequentially, and not themselves compressed. Log files are an ideal example. Compressing files which are less than 4kB or already compressed (like .zip or .jpg or .avi) may make them bigger as well as slower. Avoid compressing executables like .exe and .dll (they may be paged in and out in 4kB pages). Never compress system files used at bootup like drivers or NTLDR or winload.exe or BOOTMGR.

Although read–write access to compressed files is often, but not always transparent, Microsoft recommends avoiding compression on server systems and/or network shares holding roaming profiles because it puts a considerable load on the processor.

Single-user systems with limited hard disk space can benefit from NTFS compression for small files, from 4+kB to 64kB or more, depending on compressibility. Files less than 900 bytes or so are stored with the directory entry in the MFT.

The slowest link in a computer is not the CPU but the speed of the hard drive, so NTFS compression allows the limited, slow storage space to be better used, in terms of both space and (often) speed.(This assumes that compressed file fragments are stored consecutively.)

NTFS compression can also serve as a replacement for sparse files when a program (e.g., a download manager) is not able to create files without content as sparse files.

Volume Shadow Copy

The Volume Shadow Copy Service (VSS) keeps historical versions of files and folders on NTFS volumes by copying old, newly-overwritten data to shadow copy (copy-on-write). The old file data is overlaid on the new when the user requests a revert to an earlier version. This also allows data backup programs to archive files currently in use by the file system. On heavily loaded systems,

Microsoft recommends setting up a shadow copy volume on a separate disk.

Transactional NTFS

As of Windows Vista, applications can use Transactional NTFS to group changes to files together into a transaction. The transaction will guarantee that all changes happen, or none of them do, and it will guarantee that applications outside the transaction will not see the changes until they are committed.

It uses similar techniques as those used for Volume Shadow Copies (i.e. copy-on-write) to ensure that overwritten data can be safely rolled back, and a CLFS log to mark the transactions that have still not been committed, or those that have been committed but still not fully applied (in case of system crash during a commit by one of the participants).

Transactional NTFS does not restrict transactions to just the local NTFS volume, but also includes other transactional data or operations in other locations such as data stored in separate volumes, the local registry, or SQL databases, or the current states of system services or remote services. These transactions are coordinated network-wide with all participants using a specific service, the DTC, to ensure that all participants will receive same commit state, and to transport the changes that have been validated by any participant (so that the others can invalidate their local caches for old data or rollback their ongoing uncommitted changes). Transactional NTFS allows, for example, the creation of network-wide consistent distributed filesystems, including with their local live or offline caches.

Encrypting File System (EFS)

Main article: Encrypting File System

EFS provides strong and user-transparent encryption of any file or folder on an NTFS volume. EFS works in conjunction with the EFS service, Microsoft's CryptoAPI and the EFS File System Run-Time Library (FSRTL). EFS works by encrypting a file with a bulk symmetric key (also known as the File Encryption Key, or FEK), which is used because it takes a relatively small amount of time to encrypt and decrypt large amounts of data than if an asymmetric key cipher is used. The symmetric key that is used to encrypt the file is then encrypted with a public key that is associated with the user who encrypted the file, and this encrypted data is stored in an alternate data stream of the encrypted file. To decrypt the file, the file system uses the private key of the user to decrypt the symmetric key that is stored in the file header. It then uses the symmetric key to decrypt the file. Because this is done at the file system level, it is transparent to the user.Also, in case of a user losing access to their key, support for additional decryption keys has been built in to the EFS system, so that a recovery agent can still access the files if needed. NTFS-provided encryption and NTFS-provided compression are mutually exclusive; however, NTFS can be used for one and a third-party tool for the other.

The support of EFS is not available in Basic, Home and MediaCenter versions of Windows, and must be activated after installation of Professional, Ultimate and Server versions of Windows or by using enterprise deployment tools within Windows domains.

   Quotas

Disk quotas were introduced in NTFS v3. They allow the administrator of a computer that runs a version of Windows that supports NTFS to set a threshold of disk space that users may use. It also allows administrators to keep track of how much disk space each user is using. An administrator may specify a certain level of disk space that a user may use before they receive a warning, and then deny access to the user once they hit their upper limit of space. Disk quotas do not take into account NTFS's transparent file-compression, should this be enabled. Applications that query the amount of free space will also see the amount of free space left to the user who has a quota applied to them.

Support for disk quotas is not available in Basic, Home and Media Center versions of Windows, and must be activated after installation of Professional, Ultimate and Server versions of Windows or by using enterprise deployment tools within Windows domains.

Reparse points

This feature was introduced in NTFS v3. Reparse points are used by associating a reparse tag in the user space attribute of a file or directory. When the object manager (see Windows NT line executive) parses a file system name lookup and encounters a reparse attribute, it will reparse the name lookup, passing the user controlled reparse data to every file system filter driver that is loaded into Windows. Each filter driver examines the reparse data to see whether it is associated with that reparse point, and if that filter driver determines a match, then it intercepts the file system call and executes its special functionality. Reparse points are used to implement Volume Mount Points, Directory Junctions, Hierarchical Storage Management, Native Structured Storage, Single Instance Storage, and Symbolic Links.

Volume mount points

Volume mount points are similar to Unix mount points, where the root of another file system is attached to a directory. In NTFS, this allows additional file systems to be mounted without requiring a separate drive letter (such as C: or D:) for each.

Once a volume has been mounted on top of an existing directory of another volume, the contents previously listed in that directory become invisible and are replaced by the content of the root directory of the mounted volume. The mounted volume could still have its own drive letter assigned separately. The file system does not allow volumes to be mutually mounted on each other. Volume mount points can be made to be either persistent (remounted automatically after system reboot) or not persistent (must be manually remounted after reboot).

Mounted volumes may use other file systems than just NTFS; notably they may be remote shared directories, possibly with their own security settings and remapping of access rights according to the remote file system policy.

Directory junctions

Directory junctions are similar to volume mount points, but reference other directories in the file system instead of other volumes. For instance, the directory C:\exampledir with a directory junction attribute that contains a link to D:\linkeddir will automatically refer to the directory D:\linkeddir when it is accessed by a user-mode application. This function is conceptually similar to symbolic links to directories in Unix, except that the target in NTFS must always be another directory (typical Unix file systems allow the target of a symbolic link to be any type of file).

Directory joins (which can be created with the command MKLINK /J junctionName targetDirectory and removed with RMDIR junctionName from a console prompt) are persistent, and resolved on the server side as they share the same security realm of the local system or domain on which the parent volume is mounted and the same security settings for its contents as the content of the target directory; however the junction itself may have distinct security settings. Unlinking a directory junction join does not delete files in the target directory.

Note that some directory junctions are installed by default on Windows Vista, for compatibility with previous versions of Windows, such as Documents and Settings in the root directory of the system drive, which links to the Users physical directory in the root directory of the same volume. However they are hidden by default, and their security settings are set up so that the Windows Explorer will refuse to open them from within the Shell or in most applications, except for the local built-in SYSTEM user or the local Administrators group (both user accounts are used by system software installers). This additional security restriction has probably been made to avoid users of finding apparent duplicate files in the joined directories and deleting them by error, because the semantics of directory junctions is not the same as hardlinks; the reference counting is not used on the target contents and not even on the referenced container itself^.

Directory junctions are soft links (they will persist even if the target directory is removed), working as a limited form of symbolic links (with an additional restriction on the location of the target), but it is an optimized version which allows faster processing of the reparse point with which they are implemented, with less overhead than the newer NTFS symbolic links, and can be resolved on the server side (when they are found in remote shared directories).

Symbolic links

Symbolic links (or soft links) were introduced in Windows Vista.Symbolic links are resolved on the client side. So when a symbolic link is shared, the target is subject to the access restrictions on the client, and not the server. 

Symbolic links can be created either to files (created with MKLINK symLink targetFilename) or to directories (created with MKLINK /D symLinkD targetDirectory), but (unlike Unix symbolic links) the semantic of the link must be provided with the created link. The target however need not exist or be available when the symbolic link is created: when the symbolic link will be accessed and the target will be checked for availability, NTFS will also check if it has the correct type (file or directory); it will return a not-found error if the existing target has the wrong type.

They can also reference shared directories on remote hosts or files and subdirectories within shared directories: their target is not mounted immediately at boot, but only temporarily on demand while opening them with the OpenFile() or CreateFile() API. Their definition is persistent on the NTFS volume where they are created (all types of symbolic links can be removed as if they were files, using DEL symLink from a command line prompt or batch).

Distributed Link Tracking (DLT)

Distributed link tracking allows applications to track files, shell shortcuts or OLE links even if they were renamed or moved to another volume within the same machine, domain or workgroup.Tracking is implemented as a system service which uses the object identifier (OID) index stored in a metafile. When the application requests a track to a file or directory, the tracking service creates the OID entry which points to the file, and file rename, copy or move operation to a NTFS v3 volume also copies the object ID. This allows the tracking service to eventually find the target file.

Single Instance Storage (SIS)

When there are several directories that have different, but similar, files, some of these files may have identical content. Single instance storage allows identical files to be merged to one file and create references to that merged file. SIS consists of a file system filter that manages copies, modification and merges to files; and a user space service (or groveler) that searches for files that are identical and need merging. SIS was mainly designed for remote installation servers as these may have multiple installation images that contain many identical files; SIS allows these to be consolidated but, unlike for example hard links, each file remains distinct; changes to one copy of a file will leave others unaltered. This is similar to copy-on-write, which is a technique by which memory copying is not really done until one copy is modified.

Hierarchical Storage Management (HSM)

Hierarchical Storage Management is a means of transferring files that are not used for some period of time to less expensive storage media. When the file is next accessed, the reparse point on that file determines that it is needed and retrieves it from storage.

Native Structured Storage (NSS)

NSS was an ActiveX document storage technology that has since been discontinued by Microsoft. It allowed ActiveX Documents to be stored in the same multi-stream format that ActiveX uses internally. An NSS file system filter was loaded and used to process the multiple streams transparently to the application, and when the file was transferred to a non-NTFS formatted disk volume it would also transfer the multiple streams into a single stream.

ReiserFS is a general-purpose, journaled computer file system designed and implemented by a team at Namesys led by Hans Reiser. ReiserFS is currently supported on Linux (without quota support). Introduced in version 2.4.1 of the Linux kernel, it was the first journaling file system to be included in the standard kernel. ReiserFS is the default file system on the Elive, Xandros, Linspire, GoboLinux, and Yoper Linux distributions. ReiserFS was the default file system in Novell's SUSE Linux Enterprise until Novell decided to move to ext3 on October 12, 2006 for future releases.

Namesys considered ReiserFS (now occasionally referred to as Reiser3) stable and feature-complete and, with the exception of security updates and critical bug fixes, ceased development on it to concentrate on its successor, Reiser4. Namesys went out of business in 2008 after Reiser was charged for the murder of his wife. However, volunteers continue to work on the open source project.