Noteworthiness[edit]

Whilst I'm sure Protogon will be something that evolves throughout the course of Windows 8's development, it is nonetheless a given at this point that the Filesystem is definitely something new - the only "rumour" aspect of this is whether or not it's a redux of WinFS. In any case, it should be inherently clear that the introduction of a new filesystem in Windows is noteworthy. -- Olipro (talk) 08:45, 6 July 2011 (UTC)[reply]

I think it's becoming apparent that Protogon isn't WinFS reincarnate. If I can source that, I'll add it. —voidxor (talk | contrib) 20:41, 2 October 2011 (UTC)[reply]

Merge[edit]

Am I the only one that thinks this shouldn't have its own article (separate from Windows 8) until we have something more to write about it? - Josh (talk | contribs) 01:31, 5 October 2011 (UTC)[reply]

Name[edit]

ReFS is for Resilient FileSystem or Relational FileSystem? Read this post http://blogs.msdn.com/b/winfs/archive/2006/06/26/648075.aspx from MS about WinFS. --Claudio91.p8 (talk) 03:18, 30 December 2011 (UTC)[reply]

The same source that told us it's now ReFS told us it's Resilient File System. We've been given no reason to believe it's related to WinFS, the Relational Filesystem. - Josh (talk | contribs) 20:31, 4 January 2012 (UTC)[reply]

named streams[edit]

Since it was a preview stage, it described only in the note, but named stream was able to be used in Windows Server 2012 R2. --106.188.5.173 (talk) 07:27, 20 July 2013 (UTC)[reply]

It was shown officially ReFS of Windows Server 2012 R2 is to support named streams. http://msdn.microsoft.com/en-us/library/cc232128.aspx#id8 --106.188.24.232 (talk) 20:47, 5 September 2013 (UTC)[reply]

Windows 8.1[edit]

Windows 8.1 supports ReFS. http://technet.microsoft.com/en-us/library/hh831724.aspx#BKMK_ReFSclient --106.188.9.179 (talk) 05:38, 1 October 2013 (UTC)[reply]

Drobo - Performance and competitor comparisons[edit]

Why is Drobo compared to ZFS and ReFS? It's not a filesystem. — Preceding unsigned comment added by StuffMaster (talk • contribs) 17:44, 28 June 2014 (UTC)‎[reply]

I have no problem with someone removing reference to Drobo if they want to, but I'm not. I think the justification for mentioning it is that both ReFS and Drobo provide ways to store files on disks. Also, from reports of disks used in Drobo being unrecoverable on computers when the Drobo fails, I suspect that they might use their own filesystem. MarkGyver (talk) 03:14, 29 July 2014 (UTC)[reply]

The criticism "offerings such as Drobo used proprietary methods which have no fallback if the company behind them fails" is equally applicable to ReFS, and in the context of this article about a proprietary filesystem from Microsoft, seems somewhat hollow. Jon (talk) 23:41, 12 January 2015 (UTC)[reply]

32-bit non-support[edit]

Hello! 32-bit Windows 8.1 doesn't support ReFS, while 64-bit versions does, out of the box. I checked it out.

ReFS, as a new filesystem was first a server technology, debuted in Windows 2012 (but not in the equivalent client OS, Windows 8). After some refinements in Windows 2012 R2, ReFS made its (limited) way into Windows 8.1 (the equivalent client OS for the 2012 R2 Server). As an important side note, Microsoft's server operating systems are 64-bit only since Windows 2008 R2. Now, probably it was easy to transfer the ReFS filesystem driver from the 64-bit server version to the 64-bit client version, and it would have been significantly harder to compile a new, 32-bit version of it, but I'm only guessing of course. It is a fact, though, that c:\Windows\system32\drivers\ReFS.sys exists on a 64-bit install of Windows 8.1, but it is missing from the 32-bit version (I checked in the installation media as well).

I am trying to find a source for my claim, since it is original research, but I couldn't yet. Can someone help me out? SyP (talk) 18:01, 6 September 2014 (UTC)[reply]

However, 32-bit Windows PE/RE has read-writable 32-bit refs.sys.And can format.
Be harder to compile is not reason.--211.127.228.179 (talk) 13:29, 9 October 2014 (UTC)[reply]

Performance and competitor comparisons[edit]

Shouldn't the first paragraph be removed ? The only source is some blog post by a guy who "read about ZFS" and speculates without really knowing what he is talking about. The claim that ZFS memory usage rules it out from "a large number of medium and smaller systems" seems entirely speculative. It's based on a comparison that doesn't make any sense of the memory usage of ZFS with deduplication enabled and ReFS with it disabled, and it's admitted in the same paragraph that ReFS doesn't have this feature and that when it's disabled "ZFS has memory requirement of only a few hundred MB" (which is vague and doesn't say anything about how it compares to ReFS).

Jon207 (talk) 10:22, 3 June 2015 (UTC)[reply]

The first paragraph is based on a source that mostly compares ReFS to a generic hardware RAID controller, so it sucks at comparing ReFS to ZFS. Remove it if you wish. That said, the section should eventually discuss all of ReFS's main competitors, which I believe includes ZFS, btrfs, and probably other RAID implementations. Disclaimer: I'm a long-time Linux user who's been using btrfs for about a year, so my biases are slanted against companies and products that don't support Linux. MarkGyver (talk) 06:56, 5 June 2015 (UTC)[reply]

"log-structured" or just "allocate-on-write/copy-on-write"?[edit]

The first reference cited in ReFS#Performance and competitor comparisons for the claim that ReFS with file integrity enabled is a log-structured file system appears to think that NetApp's WAFL is a log-structured file system. Leaving aside the question of whether it's a file system at all (the initial white paper by Hitz et al says it is, and I'm not sure why Dave later didn't see some of the holes in Kostadis Roussos's argument that it isn't), it's not log-structured in the sense that, to quote the Osterhout/Rosenblum paper, it "writes all new information to disk in a sequential structure called the log".

WAFL is an "allocate-on-write" file system, to use Microsoft's phrase, or a "copy-on-write" file system, to use NetApp's phrase, in that, if any block other than one of the superblocks is rewritten, a free block is located, the new data is written into the free block, and whatever block contained a pointer to the old location is rewritten to contain a pointer to the new location, and that block is itself reallocated, all the way to the top, until the superblock is reached; the copies of the superblock are then overwritten when all the other writes have completed.

WAFL does have a transaction log, so that any operations that haven't yet been completed on the disks are recorded in the transaction log and can be replayed in case the system crashes before they are written to disk, but they're stored in battery-backed RAM separate from the disk array.

See NetApp's original white paper on the design of WAFL, which, while it cites a paper by John Ousterhout and Fred Douglas about log-structured file systems, does not go so far as to say WAFL is a log-structured file system (although it does say it's a file system!).

So, while I wouldn't call that reference an unreliable source, I might call it a somewhat confused source - while a log-structured file system is an allocate-on-write/copy-on-write file system, not all allocate-on-write/copy-on-write file systems are necessarily log-structured. One of Microsoft's own documents on ReFS says that "One of the approaches we considered and rejected was to implement a log structured file system." That paper says that "we chose an allocate-on-write approach that never updates metadata in-place, but rather writes it to a different location in an atomic fashion", i.e. allocate-on-write/copy-on-write for metadata; it goes on to say

In addition, we have added an option where the contents of a file are check-summed as well. When this option, known as “integrity streams,” is enabled, ReFS always writes the file changes to a location different from the original one. This allocate-on-write technique ensures that pre-existing data is not lost due to the new write. The checksum update is done atomically with the data write, so that if power is lost during the write, we always have a consistently verifiable version of the file available whereby corruptions can be detected authoritatively.

which sounds as if, by default, ReFS does allocate-on-write/copy-on-write for metadata but not data, but does it for both metadata and data if "integrity streams" is enabled.

(Yes, that's a primary source, but there's nothing magical about a secondary source that, merely by virtue of being secondary, makes it more reliable than a primary source. ReFS is a "white box" to the people who implemented it, so they know what's inside; it's a "black box" to somebody just doing performance tests on it without seeing the code or any design papers on it, so they don't know what's inside, and their opinions about the details of what's inside are, well, somewhat unreliable, as they're making guesses. And, in this particular case, the guesser has confused allocate-on-write/copy-on-write with log-structured in the case of WAFL, so they may interpret behavior that indicates allocate-on-write/copy-on-write behavior as evidence to indicate that the file system isn't just allocate-on-write/copy-on-write but is log-structured.) Guy Harris (talk) 10:07, 11 October 2016 (UTC)[reply]

Page needs update[edit]

A lot has been happening with ReFS in the past few years. This page is in desperate need of an update by someone knowledgeable on ReFS. Windows Server 2016 and Windows Server 2019 preview have much better support. Additionally, it was recently announced that Microsoft has pulled support for creation of new ReFS volumes from Windows 10 Pro. The new Windows 10 Workstation has full ReFS support as does Windows 10 Enterprise. — Preceding unsigned comment added by 184.174.144.140 (talk • contribs) 14:35, 26 April 2018 (UTC)[reply]

I can't claim to be "someone knowledgeable on ReFS", but I just made some fixes to the article regarding the removal of the ability to create ReFS volumes on all editions except Enterprise and Pro for Workstations. --Dan Harkless (talk) 05:47, 20 September 2018 (UTC)[reply]

A Commons file used on this page or its Wikidata item has been nominated for speedy deletion[edit]

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for speedy deletion:

You can see the reason for deletion at the file description page linked above. —Community Tech bot (talk) 09:51, 10 July 2022 (UTC)[reply]

Maximum file size[edit]

I propose we change the maximum file size to what the provided source from Microsoft has documented, 35 petabytes.

As of 2023-01-20, the article states: "... ReFS supports a maximum file size of 16 exbibytes (264−1 bytes), and a maximum volume size of 35 petabytes."

The maximum file size was written as 16 exbibytes on 2013-07-15, originally with (what I believe was a theoretical) maximum volume size of "1 Yottabyte" --at some point the volume size was changed to its actual limit of 35 petabytes but file size was not.

Are there any objections to this proposed change? On3moresoul (talk) 23:41, 28 January 2023 (UTC)[reply]

Categories