Preview build causes errors in storage spaces on multiboot system

DIY desktop computer used as test box. Both production (build 10586) and development (build 14322) installed.

I use storage spaces (two 1TB drives pooled in two-way mirror, ReFS formatted) with build 10586 for backups and archives.

Whenever I restart into build 14332 the storage spaces drives show constant disk activity and Storage Spaces does not appear in the This PC window in build 14332. When I return to build 10586 I again have a lengthy period of disk activity once more. However the Storage Spaces does appear in the This PC window in build 10586 as expected and I can access the space just fine. I get messages that Storage Spaces needs attention and when I access the Storage Spaces window via the Control Panel the drive statuses show that repair is under way. After a few minutes the drive statuses change to OK. However, the status bar at the top of the Storage Spaces area remains orange and I have a warning message. This status persists over restarts of build 10586.




Question 1: Since the physical drives section shows that the devices are OK, where can I check further for the exact problem?

Question 2: How can I clear the warning message if in fact ReFS has fixed itself?

Question 3: Is there a method to preventing this the next time I boot into a preview build short of turning off or physically disconnecting the pooled drives?

I have posted feedback, although I mistakenly left the type as "suggestion."

Here is the disk management panel (build 10586):



The storage spaces volume does not show up in the preview (build 14332).

I would like to clear the warning message circled in the first screen shot above and would like not to have to disconnect the drives before accessing the preview. Thoughts?

(also posted in Windows 10 Insider forum)

The thing that springs out at me is that the pooled storage is attached by ATA for the WD, and by USB for the ST.

There will be differences in speed and protocols in getting the data synced over both drives.

They would surely be better if both were attached directly by SATA using a single protocol?

Fafhrd said:

The thing that springs out at me is that the pooled storage is attached by ATA for the WD, and by USB for the ST.

There will be differences in speed and protocols in getting the data synced over both drives.

They would surely be better if both were attached directly by SATA using a single protocol?

As it turns out, the eSATA connection was not seen as ATA by the preview. It should have been, but it was seen as RAID instead. That's a bug and I reported it via the Feedback Hub. I switched out HDD enclosures to remove the eSATA enclosure and replaced it with a USB 3.0 enclosure. That solved the issues in the preview and removed the trouble report on the build 10586 side as well. The issue with RAID is that RAID is not compatible with Storage Spaces and the false detection set off the chain of events. Here is a screenshot of the problem before switching enclosures.



In build 10586 the eSATA drive was identified correctly as ATA. In build 14342 it was misidentified as RAID. It is fine to mix ATA and USB, but all RAID must be disabled before pooling a device and creating a storage space. Hence the craziness.