Pulling The Rug: Microsoft’s ReFS

Written by Nick Lowe on January 17, 2012 Categories: Insight

I read with interest the posting on Microsoft’s new file system, ReFS, over on Microsoft’s Building Windows 8 blog:

Building the next generation file system for Windows: ReFS

For programmers who work with any of the interesting features of NTFS and have not read it yet, they should find the time to do so. It is, potentially, just about to disrupt their world.

One of the goals for the file system is apparently to:

Maintain a high degree of compatibility with a subset of NTFS features that are widely adopted while deprecating others that provide limited value at the cost of system complexity and footprint.

And snuck away in the FAQ section is the following:

Q) What semantics or features of NTFS are no longer supported on ReFS?

The NTFS features we have chosen to not support in ReFS are: named streams, object IDs, short names, compression, file level encryption (EFS), user data transactions, sparse, hard-links, extended attributes, and quotas.

Mapped to File System Attribute Flags, the following are not going to be supported:

    The file system supports named streams.
    The file system supports object identifiers.
    The file system supports file-based compression.
    The file system supports the Encrypted File System (EFS).
    The file system supports transactions.
    The file system supports sparse files.
    The file system supports hard links.
    The file system supports extended attributes.
    The file system supports per-user quotas.

This is a large list of features that are not going to work in ReFS, at least in its initial implementation. It has the potential to have significant compatibility implications and to break many of the existing applications that are in use today.

To ensure compatibility of applications going forward, developers should ensure that they properly check that a feature is available before attempting to use it. This comes with a caveat:

The FILE_SUPPORTS_HARD_LINKS, FILE_SUPPORTS_EXTENDED_ATTRIBUTES, FILE_SUPPORTS_OPEN_BY_FILE_ID and FILE_SUPPORTS_USN_JOURNAL flags were only added in NT 6.1 (Windows 7 and Windows Server 2008 R2) and yet support for all of them has been implicit since NTFS 3.0 that was introduced with NT 5.0 (Windows 2000). A literal check for NTFS by name is therefore also needed to determine the implicit presence of these features.

(It is important to also ensure that such literal checks for NTFS by name are only performed to determine the implicit support of these features and for no other purpose. This is to ensure that applications are as forward compatible with other file systems as is reasonably possible by not taking a dependency on NTFS.)

For applications that depend on any of the features that are not available, appropriate workarounds will have to be found or a declaration made that they are not compatible with the underlying file system due to a lack of feature support.

This information is available in the Win32 subsystem via GetVolumeInformation and GetVolumeInformationByHandle, and at the underlying NT layer via NtQueryVolumeInformationFile.

The good news? Many of the features that are missing are relied upon heavily in Windows internally. This explains why it will not be possible to use ReFS as the file system for the boot volume. ReFS appears to be merely in its infancy and it has simply not been implemented fully yet, many of the missing features to appear by the time the file system becomes available in client versions of Windows.

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>