none
ReFS Corruption When Filled To Capacity?

    Question

  • We have a 100GB ReFS volume.  The volume was filled to capacity and now the volume is unaccesible.  If you click on the drive letter in Windows Explorer it displays the following "W:\ is not accessible.  The volume repair was not successful."  There are several events in the system event log for event ID 133. "The file system detected a checksum error and was not able to correct it.  The name of the file or folder is "<unable to determine file name>"."  I have tried added additional space to the drive via Disk Management as well but it failed with the following error.  "The volume cannot be extended because the volume does not contain a recognized file system."

    Anyone have any ideas on how to fix an ReFS volume?

    So far I am not too impressed with this "resilient" file system...

    Thursday, October 18, 2012 1:50 PM

Answers

  • Hi Nick,

    The issue could be caused by that the total size and free space is same. We could run the following command to check that:

    diskpart
    list disk
    sel disk
    list vol
    sel vol
    detail vol

    Thanks,

    Kevin Ni


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Thursday, October 25, 2012 5:25 AM
  • Hi, 

    Yes, the same space of total space and free space is the reason why drive could not be restored correctly and we recieved the error message. For RAID 5 corruption, currently there is no fix to fix the issue except rebuilding. Thanks. 

    Kevin Ni


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, October 26, 2012 7:29 AM

All replies

  • Hi Nick,

    The issue could be caused by that the total size and free space is same. We could run the following command to check that:

    diskpart
    list disk
    sel disk
    list vol
    sel vol
    detail vol

    Thanks,

    Kevin Ni


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Thursday, October 25, 2012 5:25 AM
  • Total size is not the same, but free space and capacity are the same.  Is there any way to fix it? 

    DISKPART> detail vol

      Disk ###  Status         Size     Free     Dyn  Gpt
      --------  -------------  -------  -------  ---  ---
    * Disk 1    Online          200 GB   100 GB        *

    Read-only              : No
    Hidden                 : No
    No Default Drive Letter: No
    Shadow Copy            : No
    Offline                : No
    BitLocker Encrypted    : No
    Installable            : Yes

    Volume Capacity        :   99 GB
    Volume Free Space      :   99 GB

    • Proposed as answer by Andem62 Thursday, March 28, 2013 11:37 AM
    • Unproposed as answer by Andem62 Thursday, March 28, 2013 11:37 AM
    Thursday, October 25, 2012 12:34 PM
  • Hi, 

    Yes, the same space of total space and free space is the reason why drive could not be restored correctly and we recieved the error message. For RAID 5 corruption, currently there is no fix to fix the issue except rebuilding. Thanks. 

    Kevin Ni


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Friday, October 26, 2012 7:29 AM
  • Hi All,

    After electrical break at shutdown process 13Tb ReFS volume becomes unavailable with same symptoms as in Nick case. Volume filled at ~8Tb.

    Volume based on Logical Disk hosted on LSI Hardware RAID controller. Level RAID-5. Data is very sensitive and should be restored.

    Please - any help appreciated!!!


    Sunday, January 20, 2013 12:01 AM
  • Sergii,

    My case was similar, after an electrical break, the ReFS formatted volume (mirrored on two hard drives) did not survived. What is funny, NTFS formatted volume located on the same hard drives survived (chkdisk corrected all errors)

    After the incident, both hard drives are healthy (no reallocated, pending or unstable sectors).

    I agree that the concept of self-healing file system is the future, but as we see, the ReFS is not ready yet. Also I could not find any data recovery option on the local market yet.

    In my opinion, people should be warned. The documentation should contain huge warning "[experimental, potential data loss possible]"


    Monday, February 11, 2013 8:18 PM
  • Yes, on my Dev server (Raid 0) on UPS also simply failed - Lucky testing on dev server so no critical data loss but I would concur that Refs needs a bit more time.
    Monday, July 15, 2013 9:41 AM
  • From what I've read, this seems to happen with the volume is filled to 100% capacity (0 bytes free).

    Microsoft better A) find a way to patch this for existing users of ReFS, and B) better fix it quick. Imagine how many people fill their disks to capacity!

    Wednesday, August 21, 2013 5:46 PM
  • From what I've read, this seems to happen with the volume is filled to 100% capacity (0 bytes free).

    Microsoft better A) find a way to patch this for existing users of ReFS, and B) better fix it quick. Imagine how many people fill their disks to capacity!

    This is how I encountered the error as well.

    I had a Server 2012 R2 VM doing automatic backups on my server, and one day when I wasn't paying attention, the vhdx file managed to expand to fill the entire partition. After the VM locked up from the lack of space, the volume became inaccessible with the same symptoms described in the OP's post.

    Has this particular issue been resolved yet? Corrupting the entire volume isn't something that a next-gen file system should ever do under any circumstances, especially under circumstances where the previous gen file system can fail gracefully.

    As a side note, I was able to recover the data using ReclaiMe File Recovery mentioned in this post, which reports the exact same issue: http://social.technet.microsoft.com/Forums/windowsserver/en-US/7abf7f65-1f0f-4766-8894-ae56b85b3700/refs-volume-is-not-accessible-file-system-shows-raw?forum=winserver8gen
    • Edited by lewisl.9029 Saturday, January 18, 2014 10:51 PM
    Saturday, January 18, 2014 10:47 PM
  • Hi Nick, Hi Kevin. Late followup on this. We are playing with ReFS on a test unit and have noticed a peculiar thread among these and other posts. There seem to be extended issues between ReFS and RAID volumes: software and specifically LSI hardware based RAID volumes.I am trying to collect some statistical information on the subject and would love your input.

    Can anyone tell me what hard drives they were using, soft or hard raid and the model of the controller? For LSI users, did the failure coincide with a patrol read or an array verification (or other block level operation, like a backup agent)?

    I put forward the premise that hardware based arrays are particularly prone to catastrophic failure if the array is doing a hardware scan at the same time ReFS is looking at its own consistency data. If the blocks fail to respond in a timely manner, the disks will not update / could be ejected from the array, causing permanent damage to ReFS and potentially punctures or unrecoverable blocks in the RAID also.

    Failing that, i would like to see where the usage data points. I am guessing that ReFS has been aimed at Windows Advanced Storage and the storage methods within, and not at soft / hard raid.

    Thanks for your time.

    Stav.

    Sunday, August 09, 2015 6:44 AM