The fact that between Windows Server 2016 TPv3 and TPv4 we moved from ReFS version 2.0 to 3.0 is something I stumbled upon by accident. In Windows Server 2016 we’re getting a new and improved version of ReFS. ReFS, (Resilient File System) was introduced in Windows Server 2012.
Since Windows Server 2016 Technical Previews we got a new capability with fsutil as it now knows about ReFS. Using fsutil we can check for the version of ReFS. The command you need for that is:
fsutil fsinfo refsinfo <driveletter>
This is something we definitely could not do in windows Server 2012 or Windows Server 2012 R2. I stumbled onto this by accident while experimenting with ReFS in the previews. Considering the ReFS focus in Windows Server 2016 R2 this is not a surprise. I noticed that.
TPv3 to TPv4 = ReFS version 2.0 to 3.0
In Windows 2016 TPv2 and TPv3 fsutil fsinfo refsinfo reports ReFS 2.0.
After installing (clean install) TPv4 I was faced with the fact that my existing ReFS formatted volumes showsed up as RAW, they could not be mounted.
I had to reformat those (or move them to a TPv3 installation to recuperate the data). When investigating this on Windows Server 2016 TPv4 with fsutil I noticed that we are at ReFS version 3.
The same actually goes for a ReFS version 3.0 volume, it’s RAW in Windows Server 2016 TPv3, unusable.
The important thing to keep in mind going forward is that from my upgrade experiences I learned that ReFS version 2 is not usable in TPv4. Keep that in mind when upgrading. You might want to get your data copied to NTFS or so if you still need it.
I also don’t know if in future technical preview release or whatever they are called then we’ll see 3.1 or 4.0 arrive. But it’s something I’ll watch very carefully when moving to those versions .
This is not a step by step “How to” but we’ll address some thing you need to do and the tips and tricks that might make things a bit smoother for you.
1) Disable Short file names & Strip existing old file names
Never mind that this is needed to be able to do continuous availability on a file share cluster. You should have done this a long time ago. For one is enhances performance significantly. It also make sure that no crappy apps that require short file names to function can be introduced into the environment. While I’m an advocate for mutual agreements there are many cases where you need to protect users, the business against itself. Being to much of a politician as a technologist can be very bad for the company due to allowing bad workarounds and technology debt to be introduced. Stand tall!
If you still have applications that depend on short file names you need to isolate and virtualize them immediately. I feel sorry for you that this situation exists in your environment and I hope you get the necessary means to deal with swiftly and decisively by getting rid of these applications. Please see The Zombie ISV® to be reminded why.
Only use the /F switch if it’s a non system disk and you can afford to do so as you’re moving the data LUN to a new server anyone. Otherwise you might run into issues. See the below example.
If you stumble on path that are too long, intervene. Talk to the owners. We got people to reduce “Human Resources Planning And Evaluations” sub folder & file names reduced to HRMPlanEval. You get the gist, trim them down.
You’ll have great success on most files & folders but if they are open. Schedule a maintenance window to make sure you can run without anyone connected to the shares (Stop LanManServer during that maintenance window).
Also verify no other processes are locking any files or folders (anti virus, backups, sync tools etc.)