ReFS on new volume, or not

[moblaw]

Oh gosh, so I wrote this down despite telling myself not to waste any space in the forum. But I could not get a clear anwser from the world-wide-web or searching trough the forum.

I have a hw raid w/bbu & flash backup + APC. The hw-r controller supports "data consistency check"

and 15x8tb=96tb disks spinning in a raid 6, "I know some of you will tell me to go nested raid 50/60" but previously I had 15x4tb for 2 years no problems, rebuild time was equal to 24-32 hours. + I have lots of cold-spares.

Should I go ReFS or stay NTFS formatting the new volume?
I really want the longer file-names and character support. I dont care for the ntfs-deduplication feature or compression.
The volume will mostly consist of 1-2 vms and act as a video archive storagepod.

I know it's safer to go with ntfs. Will using refs with this setup cause a premature-failure or mental meltdown later because of a X or Y issue?

 

[manxam]

Will you be using Hyper-V on this server? The reason that I ask is that this is where ReFS really shines with it's ability to pre-allocate blocks immediately, supports block cloning, works on metadata instead of the file directly making checkpoints near instantaneous, etc

More HERE

 

[acquacow]

I have found zero utilities for ReFS recovery and have already had it hiccup on me twice, so I went back to NTFS in storage spaces. There are a million tools that can re-assemble NTFS.

 

[moblaw]

Thanks for reply, both of you.

#2 I dont run that many instances of vm anymore, so It's mostly videoarchives.

#3 Spot on. But I have never experienced the need for a ntfs-recovery to begin with. I dont even know if one could recover ntfs-data from an array that have failed due to missing drives or rebuild/silver failure?

If you have had hiccup twice, that's already two times to much. I will probably stick with ntfs, although I can be sassy about wanting longer file name support, and throwing the old-dino ntfs out the widow, I better rethink that idea .

 

[acquacow]

I was testing some extreme edge cases though.

The one that still bugs me the most is that I had my LSI adapter passed through to a win10 VM in ESXi. I built my array there, and then later transferred the disks and controller to a physical win10 box and it couldn't recognize the array. Putting the controller back in the ESX box and passing it through to the VM again, the array was still not recognized.

 

[manxam]

For a pure file store, NTFS is still faster...

 

[ecosse]

Can't confirm they work but there are a heap of tools claiming Refs recovery

ReFS Recovery
Solved: Restore Lost Files from ReFS Partition in Windows 10 – EaseUS
Recover Deleted Files. Features: ReFS NTFS, exFAT, FAT; Apple HFS+; Unix UFS, XFS, JFS; Linux Ext2/Ext3/Ext4 & BtrFS Recovery
2018 Free Undelete and File Recovery tool by R-TT

I had an issue way back in Windows 2012 so I went back to NTFS - basically I had identical drives with different fill sizes even though they contained the same files. The support on the MS site was shocking / non-existent which for a feature that holds data is irresponsible IMHO. I would hope by now they have their house in order but I'd probably stick with NTFS.

 

[moblaw]

Thanks all. I went with NTFS, as it seems Microsoft somewhat wants to "make" ReFS EOL.

 

[cesmith9999]

It is not that they want to make it EOL. MS is making ReFS the foundation to their hyper-converged product S2D. and NTFS is for everything else. not much development is going into standalone ReFS in 2019. almost all of it went to S2D.

Neither are going away soon.

Chris

 

[Evan]

I still thought eventually MS wanted to move everything to ReFS, but certianly NTFS seems to be going nowhere fast.

 

[cesmith9999]

ReFS fixes a lot of problems super long file names and super long paths and instant snapshots of VHDX files, but it was (and still is) not feature equivalent (especially in speed on multi-socket servers) with NTFS.

NTFS is still being worked on, but not as hard as ReFS.

Chris

 

[PnoT]

Ask DPM 2016+ users how they're loving ReFS with "Modern Backup Storage"

The guys and gals at Veeam love it as well!

I've had success running it for Hyper-V workloads and there are some benefits but once that volume starts to fragment the whole thing comes down. We've had to completely format 10TB volumes that are provided to DPM ever 3-4 months because ReFS simply can't keep up with any type of churn. Backups go from 10-15 minutes to complete to 8-12 hours. There are thousands of posts on the MS forums and just as many on the Veeam boards as well discussing their woes about how slow the file system gets.

Hopefully, MS will make some improvements and fix these issues but after 10+ patches to ReFS dlls and countless registry tweaks later.. nada.

 

[muhfugen]

I have found zero utilities for ReFS recovery and have already had it hiccup on me twice, so I went back to NTFS in storage spaces. There are a million tools that can re-assemble NTFS.

They exist. I for the life of me cant find it again, but I did find software which could do it for ReFS on top of S2D when my 2 node blew up for the 3rd time in two years.

 

[NISMO1968]

Why do you think so?

Thanks all. I went with NTFS, as it seems Microsoft somewhat wants to "make" ReFS EOL.

 

[gea]

ReFS is based on the ideas that ZFS invented like CopyOnWrite and Checksums.

While on ntfs a crash during an atomic write (data + metadata) or raid write (partly written raid-stripe) can lead to a corrupted filesystem or Raid-array, CopyOnWrite ensures that an atomic write or raid stripe write is done completely or discarded to avoid a corrupt filesystem/raid by design. If somethings happens with the data, checksums on metadata and data detects the problem (data checksums is mandatory with ZFS, only an option wth ReFS) and auto-repairs the affected databloch or metadata on access or scrubbing.

This is why there are no chkdsk tools on ZFS (or ReFS) needed or available as the build-in consistency has reached a level that when its broken you need a backup or a very special toolset for recovery tools not suited for an end-user.

 

[Dreece]

Personally I've been tinkering with ReFS a great deal, across HW Raid and as standalone across both SSDs (exc. NVME) and SAS HDDs...

ReFS may not be the benchmark speed queen of formats, but what it does bring to the table is resilience and safeguard against bit-rot, altogether meaning solid integrity for VM disk files (checkpointing speed etc is but one advantage)...

I would only personally recommend ReFS filesystem for VM disk storage and archiving purposes. NTFS is still the speed and feature king in the Microsoft domain.

ps. Which format one goes with does indeed depend on deployment infrastructure. Many orgs are now relying on ZFS backend storage offering up shares and/or iscsi targets accelerated by RDMA, in the aforementioned infrastructure scenario both NTFS and ReFS are practically irrelevant as host filesystems, however, in the iscsi raw target case I have found NTFS as guest filesytem to outperform ReFS a great deal so there is practically no advantage of ReFS as a guest filesystem, for ZFS is already doing all the resilience plumbing at the storage host. (though this presumption does not take into account caching, there could be an edge case scenario where ReFS as guest filesystem brings some additional resilience benefit at the cost of some speed loss, like all things, so many variables, headache-worthy)

In the Microsoft corner the equivalent of the above is Storage Spaces Direct, which I personally have not 'tinkered' with, yet.