Public
| Alex | |
Rolled back:
* [D] [Issue #15586] If a pool is found before the disk driver has a chance to finish loading, wait for the disk driver
to load for 30 seconds.
In 2.2.0.622.
I was wrong, that was not an issue at all.
Public
| Alex | |
* [D] [Issue #15586] If a pool is found before the disk driver has a chance to finish loading, wait for the disk driver
to load for 30 seconds.
Public
| Alex | |
The problem is, in both log files, that the disk driver cannot be informed by the file system driver to create the physical disk in order to represent the pool.
DrivePool uses 2 kernel drivers that communicate in order to mount the pool, and they work like this:
- The file system driver (covefs) registers for new volume arrival notifications.
- When a new volume arrives in the system, covefs examines the root directory for a pool part folder.
- If a pool part folder is found, it reads the pool ID and then either creates a new pool or adds the new pool part to an existing pool.
- When it needs to create a new pool, it informs the plug and play virtual controller driver (covefs_disk) to create a new virtual disk. It does this using something called device interfaces. (this is the part that's failing here).
- After a new disk arrives in the system, NT will read the partition table and ask each registered file system if it can mount the file system on each volume.
- In our case, covefs comes back and says to NT that it can, and a new pool is born.
So 2 drivers are involved, covefs and covefs_disk. Covefs is a file system driver (non-plug and play) and so it won't be visible in device manager, but covefs_disk is a plug and play driver and should be visible.
covefs_disk looks like this:
From the trace, both drivers appear to be working correctly. The issue is that covefs detects the pool part 2 seconds before covefs_disk is loaded. I'm not exactly sure why that is, so I'll add some code in covefs to wait for the disk driver for 30 seconds before failing a pool mount and I'll make a new build.