Update: Microsoft will be moving away from UserVoice sites on a product-by-product basis throughout the 2021 calendar year. We will leverage 1st party solutions for customer feedback. Learn more here.

TJ Cornish

My feedback

  1. 122 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    TJ Cornish commented  · 

    @MartinB,

    Flash storage doesn't prevent degradation; the fragmentation still occurs due to IMO poor software design. The 4% SSD storage is a band-aid; it just provides enough IOPS for the fragmented data to mask the problem.

    Reading between the lines here and on the Veeam forums, there are two issues - firstly ReFS is poorly implemented in the OS. It's especially bad in 2016, and somewhat better in 2019, but still requires a large number of registry tweaks and a couple hotfixes to remotely work, if you can call its current state working.

    The second issue is the lack of management of the fragmentation. I don't know if this is DPM's fault or the OS's fault, but we have known how to deal with fragmentation for a long time. Increasing the ReFS chunk size from 4KB to 64KB as Veeam does would cut the fragmentation problem down by a factor of 16X at the cost of some lost disk space efficiency.

    Other than DPM2016/2019, I haven't had to care about managing disk fragmentation in 15 years. I don't understand why MS created a file system that is either intrinsically broken or at best requires herculean out of band management effort to keep running. I also don't understand why it has been broken for 5 years.

    TJ Cornish supported this idea  · 
    An error occurred while saving the comment
    TJ Cornish commented  · 

    Dear Azure Team on UserVoice, throwing hardware at this design problem is a band aid. Increase the ReFS chunk size from 4K to 64K like your competitors do, build in some periodic defrag, or something. I'm attempting to do a storage migration of a 380GB highly fragmented protection item and at the rate it's going now, it will take 53 hours to complete, and this is on a mid-size SAN.

    This is utterly unusable.

    P.S - for the next 53 hours my DPM server is dead in the water as storage migration preempts all other jobs on the server. I hope nobody needs a restore.

  2. 22 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Site Recovery  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    TJ Cornish commented  · 

    We need this also. Right now Azure is like Hotel California - you can check in to Azure, but you can never leave.

    We are accustomed to Hyper-V Replica where we can start with a machine in any location and fail it over to another location. Currently there is no way to initiate ASR from a machine that originated in Azure back to on-prem; and furthermore the button "Complete Migration" if accidentally pressed breaks the link to on-prem, and the only way to restart this is to copy the VHD down to on-prem, then re-setup the link.

    TJ Cornish supported this idea  · 
  3. 284 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    20 comments  ·  Virtual Machines » Windows  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    TJ Cornish commented  · 

    This creates a problem when trying to retrieve a VHD back to on-prem - the fully-populated VHD size may exceed the disk space of the on-prem machine, even though the used data of the VHD is small.

  4. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Virtual Machines » Bugs  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    TJ Cornish commented  · 

    This one isn't going to happen - sorry. The new portal is better in nearly every respect. Spend some time in it and you will find what you need.

  5. 361 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    25 comments  ·  Virtual Machines  ·  Flag idea as inappropriate…  ·  Admin →

    The status of this item has been moved back to Under Review. We initially planned to move to VHDX support as part of our support for HyperV Gen2 VMs, but we ended up using the VHD format for Gen2 VMs as well. Some aspects of the Azure Infrastructure do not cleanly support VHDX OS or data disks. So this feature is dependent on some of these internal services being updated which is an ongoing process.

    TJ Cornish supported this idea  · 
    An error occurred while saving the comment
    TJ Cornish commented  · 

    Agreed - "Cloud First" is running on a platform 2 generations old. Let's go here folks!

    We need VHDX support because of the time it takes to downconvert during an Azure Site Recovery failover operation. This adds 20 minutes to an hour to recovery time.

Feedback and Knowledge Base