Code Change Request

# 27679

Back to Code Changes

Christopher
Technical Support
StableBit DrivePool
2.2.0.877
Windows 10 (64 bit)
Public
Alex
Unfortunately it looks like at some point (probably in Windows 10) boot time logging has stopped working due to a registry change in Windows. I've fixed the issue and have revamped the logging code to make it more useful.

Boot time log files will now be separate from regular trace log files, and when boot time logging is enabled, boot time -> regular tracing will switch over automatically after the service completes startup. This allows for a clean delineation between boot time and run time. Additionally, boot time log files are now auto-flushed every 1 second to prevent Windows caching issues that may yield incomplete traces.

Normally, to get a clean trace, after the system reboots (for boot time logging), you should wait until the service finishes starting and then turn off file system tracing from the UI in order to close / flush the log files. But now, even if you simply copy the files after reboot, they should no longer be empty.
Public
Alex
* [Issue #27679] Boot time logging trace files are now named *.Boot.etl to differentiate them from regular file system trace files.
* [Issue #27679] The switchover from boot time logging -> regular file system logging now takes place at the end of service startup.
                 The initial state of file system logging is controlled by CoveFs_TracingEnabled (which is disabled by default). If
                 boot time logging was taking place, then file system logging will always be enabled by default with a 1 second 
                 flush to disk.
* [Issue #27679] Boot time logging now flushes the log to disk every second.
* [Issue #27679] Fixed boot time logging generating empty trace files.
Public
Alex
I can see in the log that one of the pools is taking some 30 seconds to mount. This isn't a big deal, but I can't reproduce this, and it should not do that. In fact, there is code in covefs that facilitates signaling among pools in order to prevent this.

I've set up a similar pool structure, 2 pools, each containing 2 physical drives, and then one root pool over those 2 pools.

So like this:
  • Root Pool
    • Pool 1
      • Drive 1
      • Drive 2
    • Pool 2
      • Drive 3
      • Drive 4
I then rebooted and in my case, all 3 pools mounted at the same time.

From my log:

DrivePool.Service.exe Information 0 [Main] Starting CoveFs... 2017-11-16 08:05:55Z 176067593
DrivePool.Service.exe Information 0 [CoveFs] Pool found on: \\?\GLOBALROOT\Device\HarddiskVolume11 (pool ID=ff8e822d-e0e4-43c9-be67-11b6382f5b1a) 2017-11-16 08:05:55Z 176251462
DrivePool.Service.exe Information 0 [CoveFs] Pool found on: \\?\GLOBALROOT\Device\HarddiskVolume9 (pool ID=bc7aa180-b4eb-4bc5-b1de-4b53fa14c47c) 2017-11-16 08:05:55Z 176253372
DrivePool.Service.exe Information 0 [CoveFs] Pool found on: \\?\GLOBALROOT\Device\HarddiskVolume13 (pool ID=87d2ad52-8fd2-4d44-ae8b-0bfe8be01a3f) 2017-11-16 08:05:55Z 176254744
DrivePool.Service.exe Information 0 [CoveFs] All 3 pools mounted. 2017-11-16 08:05:55Z 176276863

So I'm not sure what's going on there.

If you can, try to get a proper boot log, the one posted on the forum is not complete.

VDS should not be involved in pool mounting. VDS might delay a service startup, but pools mount completely independently from the service (when CloudDrive is not concerned). Covefs and Windows PnP control pool mounting.