New
#11
Yes, it is odd. What about event viewer?
@dalchina: I am not sure, unfortunately.
Apologies, I have to leave, will be back later.
That at least suggests hope the disk warnings are early indications.
My best guess right now for recovery would be to revert to 1703. But it is only a guess.
Before making any changes I would generally recommend creating a full disk image to preserve what you have- but here you have a complex situation with a lot of data. Plus the possibility the image would fail on the suspect disk.
You could at least image your system disk, then revert ('Go back to the previous build'), then you've access fairly readily to 1703 and 1709.
Ideally someone else here who uses Storage space and has upgraded to 1709 would comment... unfortunately there seems a complete lack of comments after the several tutorials on this- which is unusual. E.g.
Create Storage Space for Storage Pool in Windows 10 Hardware Drivers Tutorials
Quick suggestion:
- shutdown
- disconnect the HEALTHY physical disk only
- boot OS
- repeat powershell commands
- paste result
Done. Here are the results:
I have not yet attempted to revert to 1703 (not sure how I do that, honestly) so this is all exactly as it was since I posted last.
By the way gents, thank you so very much for working with me on this. Your efforts, however fruitful they end up being, are appreciated. I will be away for the next few hours but I'll try to run any further tests and post back here again by morning.
Bad news. Every one of three disks is functionally OK and holds data, but it is splitted from the rest two, so former RAID array falled into three incomplete and nonfunctional pieces (because RAID metadata became inconsistent). No idea why this happened.
I agree with dalchina, the next step should be reverting back to previous build (run PC Settings, click Update & Security, Recovery, Go back to the previous version). A little chance it can help but let's try it.
If it does not helpwe can try to repair metadata but it may be unrecoverably destructive operation. This option uses reset-physicaldisk command:
"If you run Reset-PhysicalDisk on a physical disk that appears as lost communication or split, this cmdlet attempts to re-integrate the disk into the Storage pool if the disk is discoverable. After you reset a physical disk, use Repair-VirtualDisk to restore its resiliency."
Reset-PhysicalDisk
Update: I am almost convinced that Reset-PhysicalDisk command returns disk into pool as empty (with data loss), so this is not an option. Unfortunately, I am not able to simulate Split disks in pool so I cannot verify it.
Before it, please attach disconnected disk, roll back to previous build, and let us know if the problem persists.
Last edited by muchomurka; 19 Nov 2017 at 04:27.
Here's a small update. I haven't yet reverted because when reconnected my healthy WD drive and rebooted I noticed something curious; Now in the storage pool screen within Windows the WD drive now shows as having the error where as the Seagate drive that HDS said was fine now still shows as fine just like it did when there were only 2 drives connected. In other words, the second drive error moved from one drive to another! Bizarre
Yes, all disks are OK, but cannot successfully form pool with volume because they lost mutual consistence. Now they are independent but only one can register the same pool unique id, and wins that one which registered it last time. You may probably revert it if you can by disconnecting two smaller disks and booting OS.
So the good news is that rolling back the 1709 version did magically resolve my issue. The bad news is that I don't know why that worked really. My pool is running NTFS so I've no explanation. VERY HAPPY right now. Backup in process. Thank you so much for the support guys!