|This article is of interest to the following WikiProjects:|
|This article was nominated for deletion on 29 December 2011 (UTC). The result of the discussion was merge to Windows Server 8.|
|Text and/or other creative content from this version of Windows Server 2012 was copied or moved into ReFS with this edit. The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists. The former page's talk page can be accessed at Talk:Windows Server 2012.|
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)
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)
- 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 --126.96.36.199 (talk) 20:47, 5 September 2013 (UTC)
Windows 8.1 supports ReFS. http://technet.microsoft.com/en-us/library/hh831724.aspx#BKMK_ReFSclient --188.8.131.52 (talk) 05:38, 1 October 2013 (UTC)
Drobo - Performance and competitor comparisonsEdit
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)
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)
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).
Performance and competitor comparisonsEdit
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).
- 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)
"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)
Page needs updateEdit
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.108.40.206 (talk • contribs) 14:35, 26 April 2018 (UTC)