ReFS Corruption When Filled To Capacity?

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...

October 18th, 2012 4:50pm

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

Free Windows Admin Tool Kit Click here and download it now
October 25th, 2012 8:25am

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
October 25th, 2012 12:34pm

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

Free Windows Admin Tool Kit Click here and download it now
October 25th, 2012 3:34pm

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
October 25th, 2012 3:34pm

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

Free Windows Admin Tool Kit Click here and download it now
October 26th, 2012 10:29am

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!!!


January 20th, 2013 12:01am

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!!!


Free Windows Admin Tool Kit Click here and download it now
January 20th, 2013 3:01am

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!!!


January 20th, 2013 3:01am

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]"


Free Windows Admin Tool Kit Click here and download it now
February 11th, 2013 8:18pm

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]"


February 11th, 2013 11:18pm

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]"


Free Windows Admin Tool Kit Click here and download it now
February 11th, 2013 11:18pm

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.
July 15th, 2013 5:46am

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!

Free Windows Admin Tool Kit Click here and download it now
August 21st, 2013 8:46pm

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
January 18th, 2014 5:50pm

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
Free Windows Admin Tool Kit Click here and download it now
January 18th, 2014 10:47pm

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.

August 9th, 2015 2:48am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics