none
Storage Pool Error: Drive or storage space Issues; check the Physical drives and Storage spaces sections

    Question

  • I created a Storage pool with the following setup. Three 3TB drives with parity all in an external enclosure with eSata and USB 2/3 ports. It was connected via USB when created and had production data loaded and tested without any issues.

    After a few days of use I decided to see what happened when I tried to access it via the eSata port. No luck, due to a driver on the eSata card issue with Win 8. So I powered all back down and plugged back in via USB. At this point the Storage pool went into the state as per the screenshot below. Any suggestions to either fix the issue and/or retrieve the data that is in the volume?


    • Edited by coreboarder Friday, September 28, 2012 1:19 AM Edit
    Friday, September 28, 2012 1:18 AM

All replies

  • Update...

    Running 'Get-VirtualDisk' I get the following:

    Running 'Get-StoragePool' I get the following:

    Friday, September 28, 2012 9:15 PM
  • Running 'Connect-VirtualDisk -FriendlyName StorageSpace' I get: 


    As mentioned in the original post I am looking for help to get bring the volume back online and get access to my data

    Friday, September 28, 2012 9:15 PM
  • With the external case plugged in via USB and powered OFF I get:

    With the case plugged in via USB and powered ON I get:

    Friday, September 28, 2012 9:18 PM
  • Computer Management -> Disk Management does not see the drives when they are plugged in and powered on:

    Friday, September 28, 2012 9:21 PM
  • Unplugging disk #3 I get: 

    Friday, September 28, 2012 9:24 PM
  • Unplugging disk #2 I get:

    Friday, September 28, 2012 9:25 PM
  • Unplugging disk #1 I get: 

    Friday, September 28, 2012 9:27 PM
  • Running 'Get-StoragePool -FriendlyName StoragePool | fl *' I get:

    Friday, September 28, 2012 9:36 PM
  • I continue to post more detail with the hope that somebody from the MS team will get involved...

    After reading all half dozen pertinent Google results I decided to see if I can retrieve any of the data using R-Studio. So far it looks like it will be another ~24 hours before it completes a Quick Scan. Running it, the Quick Scan, I get the following:


    • Edited by coreboarder Saturday, September 29, 2012 1:44 PM typo
    Saturday, September 29, 2012 1:44 PM
  • Hi,

    Thank you for your question.

    I am trying to involve someone familiar with this topic to further look at this issue.

    Regards,

    Leo   Huang


    Leo Huang

    TechNet Community Support

    Monday, October 1, 2012 8:43 AM
    Moderator
  • Minor update: R-Studio completed its scan but was unable to provide me with anything very tangible. At this point I feel like I have exhausted the known options (Storage Pool documentation is almost as spartan as its Win 8 UI) and am looking forward to getting some help from whomever you involve.
    Tuesday, October 2, 2012 1:29 PM
  • Should I be cross posting in another forum?
    Saturday, October 6, 2012 1:00 PM
  • Is there any way to get somebody to help with this? Put mildly I'm a bit perplexed that nobody from Microsoft is jumping on this. There's a wealth of detail related to what I see as a rather catastrophic failure of Storage Spaces triggered by a basic step. ANY feedback at all would be greatly appreciated.
    Thursday, October 11, 2012 4:25 PM
  • Update: It has been one week now since I have emailed three Microsoft Windows 8 team members via their respective blogs on http://blogs.msdn.com. No responses.
    Monday, October 15, 2012 1:00 PM
  • Adding more detail to the story. In this case I noticed that I had not mentioned the version of Windows.

    Wednesday, October 17, 2012 9:14 PM
  • Have you tried running a 'Repair-VirtualDisk'?

    If not, let's try a 'Repair-VirtualDisk -FriendlyName StorageSpace'.

    Robert Mitchell

    Microsoft Corp.


    Robert Mitchell Senior Support Escalation Engineer Microsoft Corp.

    Saturday, October 20, 2012 3:55 PM
  • I ran Powershell as Administrator and ran 'Repair-VirtualDisk -FriendlyName StorageSpace' and got the following error message: The system cannot find message text for message number 0x%1 in the message file for %2.

    The current status is unchanged:


    • Edited by coreboarder Tuesday, October 23, 2012 12:41 PM Added image text as actual text.
    Monday, October 22, 2012 9:42 PM
  • Is there a list of Powershell or other commands somewhere that I can run through? 
    • Edited by coreboarder Tuesday, October 30, 2012 5:36 PM update
    Monday, October 29, 2012 4:16 PM
  • To date all of the following have been run:

    • Get-VirtualDisk
    • Connect-VirtualDisk -FriendlyName StorageSpace
    • Get-StoragePool -FriendlyName StoragePool | fl *
    • Repair-VirtualDisk -FriendlyName StorageSpace

    The issue is still unresolved.

    Tuesday, October 30, 2012 5:40 PM
  • Hi Leo,

    Have you been able to locate anybody to help resolve this?

    Sunday, November 4, 2012 6:09 PM
  • As repeatedly mentioned I'm still wondering if there's another area where I can find a succinct list of troubleshooting options for Storage Pools...
    Tuesday, November 6, 2012 6:37 PM
  • Do you have any other suggestions to try?
    Sunday, November 11, 2012 9:48 PM
  • Hi Leo,

    I have emailed you once a week and have been routinely posting on this thread without any response. I'm quite surprised that this is essentially being ignored. Additionally I have emailed ANYBODY on the Windows 8 team who has a blog with a contact form. Ditto on the response rate there too.

    Let me repeat that this is not a beta installation of Windows 8.

    Saturday, November 17, 2012 12:19 AM
  • Hi,

    Please check if we have configured the pool correct. Two useful blogs for your reference:

    http://blogs.technet.com/b/kirannr/archive/2012/07/28/windows-8-storage-spaces-detailed-pooling-redundant-disk-space-for-all.aspx

    http://blogs.msdn.com/b/b8/archive/2012/01/05/virtualizing-storage-for-scale-resiliency-and-efficiency.aspx

    Thanks,

    Spencer


    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, November 22, 2012 11:47 AM
  • I have what appears to be the same issue (also Windows 8 Pro). Unfortunately I am not permitted to post a screenshot, but it looks pretty much like the one above: Storage Spaces reports "Error Inaccessible; check the Physical drives section"; Physical drives all report "Okay".

    Monday, December 10, 2012 10:53 AM
  • Hi coreboarder,

    I have what appears to be the same issue as you. Have you found a solution to your problem?

    Thanks,

    Mark

    Tuesday, December 11, 2012 4:12 AM
  • Hi Spencer,

    Thank you but the links provided are not terribly helpful for this specific situation. The pool was built using the UI, not PowerShell. Using the UI reduces the alternative paths to essentially zero when building a parity based Storage Pool. The root error has been identified above as being directly related to a physical connection change event. In this case USB <-> eSata. The big issue here is that a production volume failed and there is apparently no way to access the data on that volume. (I could wax lyrical about what my options would be if this was ZFS but that would not be productive.)

    So for anybody else just skipping to the last few comments. There is no hardware or initial configuration problem. This is a problem with how the pool reacts when you attach it using a different physical connector. USB/eSata.



    • Edited by coreboarder Tuesday, December 11, 2012 5:03 PM
    Tuesday, December 11, 2012 4:33 PM
  • No I have not found a solution. (I have Googled, posted on other forums, emailed members of the team via their blogs, and bumped this thread in the last three months.) 

    Some possibly useful points:

    • I noticed a significant speed increase on another test system recently after an update was applied. When I say significant I really do mean it. Write speeds (burst to one drive and distribution to the others?) have gone up an order of magnitude under rather specific circumstances. Read remains so so still. ('so so' means just above minimum for the specs.) I hope that this change may mitigate the issue detailed in this thread for anybody going forward so it may be worthwhile to see what patch levels you were at when the issue occurred. Patterns of the obvious as they say...
    • Recovery. Seriously, I just want to know that data can be retrieved from a pool if something that could be as basic as a bit setting goes bad. Give me a PowerShell utility or anything. Just give me something that can be told "here's the disks that make up the pool and go see what you find." Clearly it does not exist (yet?) as is painfully evident from above.
    • Going forward I may be done with this issue. From my viewpoint, based on my disastrous experience, it's obvious something is up. Dramatic performance improvements are the real world reflection of non trivial code change and supporting technical decisions. That says something new was found or worse, something old remembered/revisited. The technology is appealing but with file systems, reliability must be absolutely unquestionable. And after that Recovery is a peer. Not a close second. Neither to me appears present with the current code base (a viewpoint compounded by your recent posts) and I'm not willing to put my neck out when it comes to real data. 
    Tuesday, December 11, 2012 5:00 PM
  • Another interesting tidbit with relation to this. During testing I have found that the speed burst previously mentioned is not really representative of what is actually occurring. The files are NOT moving from source (internal drive) to target (Storage pool) with the speed as displayed by the UIs progress bar. 

    For clarification take the following scenario...

    1. Move a 1Gb file from C: to the Storage Pool by dragging and dropping, cut and paste, or other.
    2. The progress bar takes less than five (5) seconds to go from 0% to 100%.  
    3. You can now delete the source file (without any sign of the usual, "are you sure" prompt which is unsettling on many levels but unrelated)
    4. You can now rest easy knowing that your target copy of the file is safe in your pool. All is safe and secure in a world of redundancy.

    What actually happens is:

    After #3 the file is really queued for transfer/distribution and the real copying of the bits happens at the original, and heroically painful slow original rate.

    Now this may not seem profound initially but dwell on the real world and very disturbing implications of this for a moment. Your UI has told you something about a file transfer that is categorically not true. In fairness to Windows 8 I'm sure the OS has every intention in the world to actually perform the transfer but... It. Has. Not. Actually. Happened. If you have a drive failure at this point you most likely will not be in a great place. Or mood.

    I've tested this by rather bravely/foolishly pulling the power AFTER the file transfer has completed and then attempted to access the pool from another machine.


    • Edited by coreboarder Monday, January 14, 2013 4:58 PM Clarity added.
    Monday, January 7, 2013 7:16 PM
  • I read this thread in awe and horror. I sympathize with you, coreboarder, deeply.

    It is likely that the support personnel are helpless in this case because the feature is so new, and indeed, poorly understood and poorly documented. Further, it is a feature that would tend to be used less by home users, and more by "power" users and administrators.

    I would suggest that if your copy of Windows is indeed genuine (and not an OEM version), that you contact Microsoft directly via phone and work from there. You are likely to get much better response from the support organization that way (if only because they can't simply ignore you).

    Friday, January 11, 2013 2:36 AM
  • Further, it strikes me that the problem may be related to how USB mass storage devices work with the underlying spinning disk. I know essentially nothing about it, but it may be that the USBMS mechanism alters the identity of the drive. That is to say, when you plugged the drive in over eSATA, it was no longer the same drive that it was when plugged in over USB.

    The fact that going back to USB did not "rescue" the pool, however, is quite discouraging.

    I wonder how much testing USB got in relation to this feature, given that USB is rarely used for the sorts of applications that Storage Spaces is meant to be applied to.

    Friday, January 11, 2013 2:41 AM
  • I m getting the same error and tried very hard to rescue however very disappointed, this is my first newly build storage spaces pool cause me big lost, this is really disaster and my advise to everyone please don't ever use storage spaces pool to keep your valuable files, it's better build or buy a NAS to reduce the chances of big lost
    Thursday, March 17, 2016 1:34 PM
  • I've had this problem, however unplugging and replugging it again (with hot plug enabled) in Windows 10 forced the storage pool to repair itself and eventually work again. Not sure if it's just my luck or a future warning of disk failure.
    Friday, January 25, 2019 8:47 PM