From the log that he posted, it looks like he's using BitLocker auto-unlock.
The problem is that when a pool is mounting, starting with .891, it will now wait 60 S (by default) for all of the known pool parts to arrive. But, it seems that BitLocker auto-unlock will not kick in as long as a drive is still mounting. I've tried various approaches, like detecting BitLocker unlocks in the kernel, not delaying the mount but instead delaying the first file open, and none of those approaches have yielded satisfactory results.
But, I've now been working on this issue for a few days and I think I've finally found a solution:
- First of all, I've lowered the CoveFs_WaitForKnownPoolPartsOnMountMs to 10000.
- I've then introduced a new setting CoveFs_WaitForPoolsAndPoolPartsAfterMountMs, and that's set to 60000 (that's what CoveFs_WaitForKnownPoolPartsOnMountMs was set to). This will force the Service to wait a maximum of 60 S for all of the pools to finish mounting, and for all of the known pool parts on all of those pools to get recognized. This happens prior to any kind of missing disk and notification processing.
The end result is a somewhat of a different pool mounting process:
- As volumes arrive in the system, they are probed for PoolParts.
- Pool virtual disks are spawned as pool parts are detected.
- As pools are mounted, if they know how many pool parts they are supposed to have, they will wait for all of those pool parts to arrive before completing the volume mount (for a maximum of 10 S -- CoveFs_WaitForKnownPoolPartsOnMountMs). This will ensure that any pools exposed to applications will always have all of the pool parts mounted, and it prevents all delays if all of the known pool parts are already present at pool mount time.
- The service will wait for all of the recognized pools to finish the step #3 mount process (for 60 S -- CoveFs_WaitForPoolsAndPoolPartsAfterMountMs).
- The service will then wait for all of the known pool parts to arrive on all of the mounted pools (for 60 S -- CoveFs_WaitForPoolsAndPoolPartsAfterMountMs). This step ensures that any drives (such as BitLocker) that were not able to unlock as part of step #3, will get sufficient time to get recognized. Normally, there will be no additional delay here.
- The service finishes startup, and all missing disk, file duplication, notification, etc... processing will begin.
This new mount process ensures that regular local pools are mounted quickly and fully, while at the same time it's flexible and allows for drives such as BitLocker.
For logging purposes, a delay in step #5 will be logged like this:
Information 0 [CoveFs] Pool 9204bf14-aa51-4081-afee-b260278301ab is missing some pool parts. Waiting... (Expected: 2, Found: 1)