"We had to destroy the Village in order to save it........."firewall68 wrote:Ok i`ve did it, but .......
According MS the update will fix the issue but you have to format the disk again with REFS. therfor all data on the RAW Device are lost.
We weren't expecting a new REFS fix with the 13 February Cumulative Update (security patch day). It was supposed to be in the later February Cumulative Update on 20 February or later, the one you have to manually trigger or get from the Microsoft Catalog.Cullan wrote:Seems to still be Refs.sys10.0.14393.203511-Jan-18
I must have missed something - but where did we find out this to be true? Haven't some users been beta testing it with success? I don't remember any of the mentioning a reformat.Mike Resseler wrote:That is not so good news
So after installing the CU, to be able to use the "fixed" ReFS driver you need to reformat. That is painful
He's telling about raw disks.Mike Resseler wrote:That is not so good news
So after installing the CU, to be able to use the "fixed" ReFS driver you need to reformat. That is painful
For me, this is a normal behaviour. RAW disks are destroyed data. No patch from microsoft can rescue this data.firewall68 wrote: According MS the update will fix the issue but you have to format the disk again with REFS. therfor all data on the RAW Device are lost.
the only way is to buy a software which can recover REFS.
Based on comments earlier, it was never going to as far as I can tell. The updates was possibly going to be released later in Feb as a standalone update, and otherwise included in the March rollupMike Resseler wrote:Keep us informed gentleman. I am not in the possibility to install updates on a workload the next couple of days but I am eager to know if it is included. From the list of files, it does indeed seem that ReFS has not received an update compared to the January CU.
) and that the manual one is the droid we are looking for...First time I hear. Who told you this?Mike Resseler wrote:So after installing the CU, to be able to use the "fixed" ReFS driver you need to reformat. That is painful
So, here I am, all eager, looking for the patch, while all my failed backup jobs are stopping and snapshots removing before I reboot my repo again... and I can't find anything....Gostev wrote:Neil is correct, these aren't the droids you're looking for. The fix is expected to be released next week (2/20) as part of a separate KB.
It must just feel like an eternity!Gostev wrote:Remember Seattle is almost 1 day back with their time zone
*
I feel like if a change from 64k to 4k was now the preferred option, Veeam would have communicated that somehow? All the guides I see still explicitly show using 64k during the format, and granted the guides are a little bit older but I'd think such a large shift would have been announced at some point.pinkerton wrote:Just got off a phone call with one some Veeam technican (3rd party) discussing WAN acceleration. At the end we talked about ReFS issues and he told me that Veeam now recommends to use 4K formatting for ReFS volumes instead of 64K. Is that true? We implemented ReFS a year ago and IIRC the recommendation was 64K back then. We also have problems with our ReFS setup and are waiting for the hotfix. However, if 64K is also cause of the issue we are going to change to 4K as well.
I'm not sure why someone from support would say that. We recommend 64K not just due to performance of merges/synthetics, although that is a factor, but primarily due to the fact that using 4K clusters leads to the problems documented in this forum thread much more often and in worse ways, even with much smaller datasets. For example, with 4K clusters I've personally seen ReFS lockups on repositories as small as a few TBs in size, and common (nightly), lockups with 100TB repositories when they contained <10TB of data. On the other hand, with 64K clusters, these smaller repos were stable as long as they had enough memory. Of course, 64K clusters did not eliminate all of the issues, as this thread well documents, it just made them less likely.pinkerton wrote:Just got off a phone call with one some Veeam technican (3rd party) discussing WAN acceleration. At the end we talked about ReFS issues and he told me that Veeam now recommends to use 4K formatting for ReFS volumes instead of 64K. Is that true? We implemented ReFS a year ago and IIRC the recommendation was 64K back then. We also have problems with our ReFS setup and are waiting for the hotfix. However, if 64K is also cause of the issue we are going to change to 4K as well.
First job finished, pre patch the fast clone took 2 hours, post patch, 25 minutes.jayscarff wrote:Same version here! Testing some backup jobs currently, copy jobs kick off in the morning which will hit the repository with multiple GFS at the same time!
Users browsing this forum: Google [Bot] and 159 guests