Building the next generation file system for Windows: ReFS

re: Building the next generation file system for Windows: ReFS

Drewfus — Mon, 23 Jan 2012 11:49:38 GMT

A few belated points and questions.

"• 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."

How does the ReFS footprint compare to NTFS? Could you compare in terms of a ratio or percent of volume used in each case?

"• Verify and auto-correct data. ... • Optimize for extreme scale. Use scalable structures for everything. Don’t assume that disk-checking algorithms, in particular, can scale to the size of the entire file system. • Provide a full end-to-end resiliency architecture when used in conjunction with the Storage Spaces feature, which was co-designed and built in conjunction with ReFS."

Considered against the first point, these three points hint that Microsoft engineers are having problems getting NTFS (and chkdsk) to scale to very large volumes with the extreme reliability required. Why go to the enormous effort of building even a semi-new FS, with a substantially reduced feature set, if that were not the case? Particularly so, given that NTFS is Storage Space compatible. Furthermore, if ReFS does not get hardlink capability, but is intended in the future to be used on boot volumes, the Windows servicing stack will have to be rearchitected to cope, presumably a major effort in its own right (or is a reworking of the notoriously slow servicing system occuring anyway?). Note that i don't intend this as a criticism - if NTFS is to be regarded as the more general-purpose FS, and ReFS as the simpler structured, ultra-scalable/reliable FS but with reduced feature set - that's fine by me. 'General-purpose' is synonymous with some sort of tradeoff.

"Being the first version of a major file system, we do suggest just a bit of caution. We do not characterize ReFS in Windows 8 as a “beta” feature. It will be a production-ready release when Windows 8 comes out of beta, with the caveat that nothing is more important than the reliability of data."

Very forthright and honest. Much appreciated. However, releasing a new, boot volume incompatible FS with a reduced feature set, when the existing FS is used nowhere near its theoretical limits, is surely begging the question. Is there a problem with NTFS scalability on very large volumes - yes or no? I suppose the question is complicated by hardware issues like 'bit rot', so the question should really be rephrased by assuming 100% reliable hardware.

"We have tested ReFS using a sophisticated and vast set of tens of thousands of tests that have been developed over two decades for NTFS. These tests simulate and exceed the requirements of the deployments we expect in terms of stress on the system, failures such as power loss, scalability, and performance."

I would like to see a blog post on MSFT's internal testing. Not regarding anything you might call 'insider information', but an overview of testing procedures with a few juicy stats and a 'factory tour' sort of feel to it, with some good pics, quotes and of course a video. Not asking for much i know, but something that gives the readers' a sense of the scale of Windows development and testing might be beneficial.

"Initially, our primary test focus will be running ReFS as a file server. We expect customers to benefit from using it as a file server, especially on a mirrored Storage Space. We also plan to work with our storage partners to integrate it with their storage solutions."

I have noticed a few comments about the perceived 'excessive' number of Windows SKUs. I tend to agree there are too many, and moving from system to system and missing/gaining features/commands/switches can be annoying. Having read the requests to get ReFS in the Win8 client, and also thinking about why the Ultimate SKU was a bit lacking in ultimate features, my (serious) suggestion is that at least one client SKU gets a limited form of Active Directory. I don't see why server capabilities should be limited to special-purpose machines, either in the home or in very small business environments. With features like Away power mode and Wake-on-Lan, i think AD on a client is a workable option. It would also be a great opportunity for young people to get some AD exposure. Suggested Windows 8 SKU set:

• Premium (64bit only) ≈ Win7 Ultimate + Active Directory (10 users) + ReFS

• Standard (32/64bit) ≈ Win7 Enterprise

• Basic (32bit only) ≈ Win7 Basic

"The Integrity.exe command line tool is a powerful way to manage the integrity and scrubbing policies."

Why didn't you extend the existing attrib.exe command for this purpose, rather than creating a new command? Presumably a cmd.exe compatible command was developed (rather than a PS cmdlet), so that like the new format /i switch, it can be used in an offline environment like WinPE?

"...all ReFS metadata is check-summed at the level of a B+ tree page, and the checksum is stored independently from the page itself. This allows us to detect all forms of disk corruption..." "Integrity streams protect file content against all forms of data corruption."

Are there security implications for all this low-level activity? I'm thinking in particular of rootkits and the ability to detect these. Will ReFS be more resilient to some forms of malware? Also, will ReFS make command switches like Imagex's /check and /integrity redundant? Have you made a FS so reliable that network hardware will become the weakest link in the data transmission chain? Quoting from technet.microsoft.com/.../2007.10.desktopfiles.aspx which states the WIM file format is...

"...susceptible to corruption. Most often this corruption occurs when a WIM file is transmitted over the network. Early on in Windows Vista, we saw specific problems with specific network cards—if they dropped packets, the WIM file was corrupted..."

Are network hardware vendors working towards the same levels of reliability that you are with ReFS?

"For these cases where the volume gets corrupted, ReFS implements “salvage,” a feature that removes the corrupt data from the namespace on a live volume. The intention behind this feature is to ensure that non-repairable corruption does not adversely affect the availability of good data."

This is an incredible level of reliability sophistication. Just a query on how it works -

"If, for example, a single file in a directory were to become corrupt and could not be automatically repaired, ReFS will remove that file from the file system namespace while salvaging the rest of the volume."

Does this work at the sector-by-sector level (if necessary), like the *nix DD Rescue command?

Regarding shadow paging, does the use of this mechanism (as opposed to the journaling mechanism used by NTFS) more or less preclude the implementation of hardlink functionality in ReFS? Quoting the Wikipedia link: "When the page is ready to become durable, all pages that referred to the original are updated to refer to the new replacement page instead. Because the page is "activated" only when it is ready, it is atomic." Are you also wanting the reference updating to also be atomic, again for reliability and simplicity reasons? (Hopefully that question makes sense given my limited knowledge of filesystems).

The section 'Reliable and scalable on-disk structures' is fascinating. Hope to see some more info on this, perhaps in Technet Magazine. A question regarding file metadata; how extensible will this be for developers and perhaps even end-users? Here are two things i would like to see supported in the new FS.

1. The notion of in-context and out-of-context filenames. An in-context filename is the normal filename supplied by the creator/owner when doing say, a Save-As. The out-of-context or floating filename, is a metadata field the user might add to a files' properties dialog. The floating filename can be used, or is used, for example, when emailing the file as an attachment. Ex:

• InContextPath = %userprofile%\Documents\Spreadsheets\<Company>\Sales\<YYYY>\<MM>

• InContextName = summary.xlsx

• FloatingName = "<Company> Sales Summary for <month>, <YYYY>.xlsx"

Hope you like my reimagining of short & long filenames!

2. A user-defined file attribute: U. Something more robust and that doesn't interfere with the A(rchive) attribute. My driver collection is organized like this:

<path>\Drivers\OSIdentifier\Class\Vendor\PackageName

I want to do this with the attrib command:

> attrib +U "<path>\Drivers\*\*\<Vendor>" /S /D

Then this with Robocopy:

> robocopy "<path>\Drivers" "<anotherPath>" /MIR /IA:U /A-:U

Is something like that conceivable with ReFS?

Sorry so late with this comment. Could you please extend the commenting window to 10 days?

re: Building the next generation file system for Windows: ReFS

John — Sun, 22 Jan 2012 14:22:31 GMT

Off-topic

Please fix the "Folders views" settings.

I've had my settings to details with customize and sort type (also make it applies to all folders in the settings). When open files with media like (jpg, png, avi etc.. ). It's random change the views to big thumbnail.

Annoying as hell.

re: Building the next generation file system for Windows: ReFS

MurrayW — Sun, 22 Jan 2012 08:25:17 GMT

I'd like to see it on the client-side, to be honest. I don't want to download an eval server OS to play with a potential feature. Sure, make us jump through hoops to enable it... but put it on the client OS... please!

And while you're at it, stop crippling other apps like VSSADMIN and the likes. You make my life hell by having a different server and client application/utility, with the same name, with wildly different functionality.

re: Building the next generation file system for Windows: ReFS

Surendra Verma [MSFT] — Sun, 22 Jan 2012 00:52:53 GMT

I'd like to thank everyone for their comments and feedback. As we stated in the blog, we believe we've advanced the state of the art for Microsoft file systems in multiple dimensions, even though we currently don't support some of the features of NTFS. We have a lot of headroom for innovation in the design, and we will evolve it in stages. As usual we'll look for feedback on functionality as we do that.

re: Building the next generation file system for Windows: ReFS

Stephen — Sat, 21 Jan 2012 04:48:16 GMT

I'd also like to echo many of the comments from this post in regards to both Metro and ReFS.

With ReFS, there seems to be so many major features that have been removed that I don't see how it would improve our organisation by using it over either a third-party file system or NTFS itself. If you want a system to replace NTFS, which ReFS appears to be, it needs to support the same features. Could we see some statistics in regards to the use of NTFS features such as Quotas and Hard Links, because I would think most organisations rely on these and won't accept a file system that doesn't support them?

In regards to Metro, I can't come up with any use case in which user's productivity will be improved on the desktop by using it. I would hope the team that suggested adding it to Windows 8 had to present some serious use cases to Microsoft's management before it was approved. I'd like to see a blog post detailing some of these. Also I don't think you'd find many OH&S people who would say that people sitting at their desks all day touching a vertically positioned is a good thing.

re: Building the next generation file system for Windows: ReFS

Chris_Gardner — Fri, 20 Jan 2012 20:41:55 GMT

Haven't yet commented on a Building Windows 8 blog entry (although I've read most of them). Felt a need to comment on this one. I've been working with Windows and storage in some capacity for almost 15 years and a lot of ReFS seems like major steps backwards. A treatise in 3 points:

1. What are we solving for? - Dependability, while important, really hasn't been much of an issue with NTFS since journaling was added. What customers have been clamoring for is better metadata handling and more robust tools to handle permissions beyond the archaic ACLs. For all its warts, Sharepoint handles both better than what I just read about ReFS. Why didn't the MS file system look to the Sharepoint team for inspiration?

2. Missing and just plain axed features - There's no good reason why deduplication shouldn't be included in a new file system. None. It's a game changer. I have a DataDomain appliance that lets me store 750 TB+ of data on 30 TB raw. Imagine something similar built into the file system of every Windows machine on the planet. If you can't do block-level dedupe, at least include single instance storage. Now to the discarded features. Quotas? Compression? Did you guys really reach out to your customers for this information? The built-in quota system sucks, but using File Server Resource Manager is really no better. This kind of thing belongs in the file system, not in userland. Compression has saved more than a few admin's bacon when they quickly need to regain some space. Your own updating system uses it on some versions of Windows. Granted, it's not nearly as powerful as some of the compression apps out there, but at least it's something. It's a hell of a lot easier to turn on compression for a folder than build an archiving system which runs ZIP/RAR/etc over and over.

3. The name - As soon as I saw the name it bothered me. Now I know why. ReFS. Sounds an awful lot like a shortened version of ReiserFS. You know, the guy who killed his wife. Did you consult with your marketing folks at all on this one? It makes about as much sense as "Windows Phone 7" (average cell phone buyer asks "What happened with Windows Phone 1-6?") Call your Xbox guys up. I'm sure they can come up with a better name in 5 minutes.

re: Building the next generation file system for Windows: ReFS

Alvaro — Fri, 20 Jan 2012 13:22:34 GMT

It's time for a new post, maybe about multitasking, multimonitor or other user related topic (to mix it up a little).

At least clos comment here. The latest comments are beggining to derail from OT to simply trolling.

(im still waiting for a post about dynamic disk booting, in the future)

Alvaro:)

re: Building the next generation file system for Windows: ReFS

Sinnfrei — Fri, 20 Jan 2012 12:01:20 GMT

I agree, Metro for desktops is a fail by design. But to be honest, designing UIs never was one of Microsoft's strong sides. Windows 8 could be a real win, if they would simply make the old UI (the standard Windows Desktop) fully customizable.

re: Building the next generation file system for Windows: ReFS

Multi desktop — Fri, 20 Jan 2012 11:52:56 GMT

Please implement multi desktop support in windows 8

Because desktop is the most used feature and it usaully gets crowded so multi desktop like ubuntu and mac would be very usful

re: Building the next generation file system for Windows: ReFS

Tim Cooker — Fri, 20 Jan 2012 09:48:29 GMT

Our legal team working very hard to find some of our patents in ReFS to sue you guys. Happy New Year.