TIA

I'm trying to remove it from the pool, but it says 45% almost instantly and is otherwise stuck.

The DrivePool interface shows no reads or writes.

I tried the "Force Removal of Damaged Drive" and this is the result.

Ideas?

Setup:
- StableBit DrivePool 2.3.13.1687
- Windows 11 (10.0.26200.0)
- ~13 drives in the pool
- Pool mounted as Z:\

What happened:
Booted up today and DrivePool showed no pool at all — just "Create a New Pool" with 3 non-pooled disks (boot drive, game drive, and one unrelated drive). Restarting the service and rebooting did not help.

What I've verified:
- PoolPart folders are intact on the drives (confirmed visually)
- CoveFs is running (STATE: 4 RUNNING, WIN32_EXIT_CODE: 0)
- All physical drives are visible to Windows via Get-PhysicalDisk (see below)
- The ProgramData\StableBit DrivePool\Service\Store folder is intact and has 99 files modified today
- Service log shows a clean startup with no errors
- `dpcmd list-poolparts Z:\ 1` shows only 1 of 13 pool parts mounted (the WD 6TB, Device 1, HarddiskVolume9)
- `dpcmd refresh-all-poolparts` did not recover the missing disks
- Ran `dpcmd hint-poolpart` on all 17 candidate volumes from mountvol output — no effect
- Restarted service after hints — no change
- The DrivePool UI does show all 13 pool slots as "Disk is missing" after interacting with the UI, so the database is intact

**Get-PhysicalDisk output:**
```
DeviceId  FriendlyName                           Size
0         TOSHIBA DT01ACA100             1000204886016
1         WDC WD6003FZBX-00K5WB0         6001175126016
2         WDC WD101EFBX-68B0AN0         10000831348736
3         WDC WD10JPVX-75JC3T0           1000204886016
4         TOSHIBA MQ04ABF100             1000204886016
5         WDC WD101EFBX-68B0AN0         10000831348736
6         Samsung SSD 990 EVO Plus 2TB   2000398934016
7         Samsung SSD 970 EVO 1TB        1000204886016
8         ASMT 2115                       500107862016
9         ASMT 2115                       500107862016
10        ASMT 2115                       500107862016
11        ASMT 2115                      1000204886016
12        ASMT 2115                      2000398934016
13        ASMT 2115                      1000204886016
14        ASMT 2115                       500107862016
15        ASMT 2115                       500107862016
16        COVECUBE CoveFsDisk_____       2199023255552
```

**dpcmd list-poolparts Z:\ 1 output:**
```
Pool ID '97e2ad00-8f62-4104-84b4-c351ebc5f756':
  - '\\?\GLOBALROOT\Device\HarddiskVolume9\PoolPart.ceaa3e43-7485-45c9-9d91-9e0e79d02d63' [Device 1]
    - Volume Size: 6,000,636,588,032 B (5.46 TB)
    - Used: 4,811,055,149,056 B (4.38 TB)
    - Free: 1,189,581,438,976 B (1.08 TB)
```

Was working fine for months. What changed today: I removed 2 drives from the pool just fine. I then added 2 new drives to my machine, and those were being scanned. Not added to the pool quite yet. I restarted my computer during this, and poof

If I assign a drive letter, the UI goes from "Disk 5" Missing, to "Disk D:" Missing. So it can see the drives in a sense.

Only that one disk is mapping. The other 12 pool members are physically present and visible to Windows but DrivePool can't attach to them. Data is safe, I just can't access the pool. Any ideas what's gone wrong here and how to force the re-association?

Is there a way to limit a drive to only store specific folders?

EDIT:

I realized I'd only tried to get this to work with folder rules, not pattern-based rules. So I'm trying the following two rules:

/VMS/* -> only SSD drive
/* -> all drives except SSD, checked "When a drive is added to the pool, files matching this rule should be placed on the drive."

Thoughts on whether that'll work as I expect?

Crash Dump Analysis
--------------------------------------------------------------------------------

Crash dumps are enabled on your computer. 

Crash dump directories: 
C:\Windows
C:\Windows\Minidump

On Sat 25/04/2026 01:53:16 your computer crashed or a problem was reported

Crash dump file:  C:\Windows\Minidump\042526-117328-01.dmp (Minidump)  
Bugcheck code:  0x44(0xFFFF9108203DB720, 0x1269, 0x0, 0x0) 
Bugcheck name: MULTIPLE_IRP_COMPLETE_REQUESTS 
Bug check description: This indicates that a driver has tried to requested an IRP be completed that is already complete. 
Analysis: This is a typical software problem. Most likely this is caused by a bug in a driver. 
 
  


On Sat 25/04/2026 01:53:16 your computer crashed or a problem was reported

Crash dump file:  C:\Windows\MEMORY.DMP (Kernel memory dump)  
Bugcheck code:  0x44(0xFFFF9108203DB720, 0x1269, 0x0, 0x0) 
Bugcheck name: MULTIPLE_IRP_COMPLETE_REQUESTS 
Driver or module in which error occurred:  covefs.sys (covefs+0x998D) 
File path: C:\Windows\system32\drivers\covefs.sys 
Description:  CoveFS File System Driver 
Product:  CoveFS 
Company:  Covecube Inc. 
Bug check description: This indicates that a driver has tried to requested an IRP be completed that is already complete. 
Analysis: This is a typical software problem. Most likely this is caused by a bug in a driver. A third party driver was identified as the probable root cause of this system error. 
It is suggested you look for an update for the following driver: 
covefs.sys (CoveFS File System Driver, Covecube Inc.). 
 
Google query: covefs Covecube Inc. MULTIPLE_IRP_COMPLETE_REQUESTS

pool1 (jellyfin media) housed in terra-master D4-320 via usb:

(ssd cache)

seagate ironwolf pro 12tb

seagate ironwolf pro 16tb

wd red pro 16tb

pool 2 (mirrored archive) housed in a second terra-master D4-320 via usb:

seagate barracuda pro 6tb

wd enterprise-grade "white label" 14tb (shucked from elements)

seagate barracuda 24tb

i have tested each individual drive in crystaldiskmark and nothing out of the ordinary in terms of speed.

what i have noticed is on the first pool, the rebalancing speed on both seagate drives move files at 250+ MB/s, while the wd drive caps at ~20 MB/s

on the 2nd pool, the rebalancing speed of the barracuda pro is ~240 MB/s, the barracuda 24tb is ~220, and the wd drive is capped at ~20 MB/s.

this cant just be a coincidence for the 2 wd drives here, since i have been following this "issue" for a while now and in every single one of these similar these cases the problem happens on wd drives:

https://community.covecube.com/index.php?/topic/5375-why-is-balancing-so-slow-is-it-just-me-or-like-this-for-everyone/

https://www.reddit.com/r/DataHoarder/comments/ji7qoh/stablebit_drivepool_is_this_slow_or_typical/

https://community.covecube.com/index.php?/topic/28020-drive-pool-balancing-speed/

https://community.covecube.com/index.php?/topic/5752-extremely-slow-balance-speeds/

now with that said, i doubt every single user with wd drives experiences this issue or else it would have been a much bigger issue since the past 6+ years it has been happening. instead i think this could be some kind of bug that only affects some wd drives specifically.

Edit: additionally, i can confirm that this bug only happens during rebalance writes. the read speed is unaffected (i tested by copying a file residing on the wd disk from the drivepool, not the individual drive, and it reads at 280 MB/s)

Edit 2: just to be a bit more thorough, i placed 14GB worth of files on the wd drive manually. then ran rebalancer so that it reads those files from wd drive and writes them to seagates. the wd drive reads at 250 MB/s and seagates writing at 250 MB/s. so yes, this is a bug that only affects write during rebalnce on wd drives.

Thanks!

I am using Drivepool on 3 separate PC's.  One of them seems to have a lot of "other" space that I can't account for.

PC1 has a 109 TB pool, 95.1 TB on unduplicated used space and 13.4 GB of "other"

PC2 has a 61.9 TB pool, 34.1 TB of unduplicated space and 6.34 GB of "other"

PC3 has a 80.1 TB pool, 67.8 TB of unduplicated space and 640 GB of "other"

None of the drives that make up these pools have any files outside of the pools folder.

If you look at the images below, the worst culprit is drive H with 464GB of "other" space, but as you can see there are no folders or files stored on this drive which are outside the pool folder.  I have tried remeasuring, and reinstalling the software and selecting repair, neither made any difference.

Thanks

when i go set Duplication setting I see blue inherit on most of the Folders ( I uses to Duplicate everything) no so much as used up the 4 TB

so how do i turn on the red "Disable" Duplication ?

I'd like to clean all Duplication and work with the 4TB pool better.

OH top software been 4 or 5 years Prefect system had few drives go down over that time Drive pool ROCKS =)

During which i had no fears for the safety of my data cos i use drivepool.

System is now back up, and drivepool had no problem recreating the drives setup as it was.

On reflection a license was some of the best money i ever spent having used all raid varieties over the last 30 years.

I'm just so grateful more faff wasnt required as wiring up a rack case is annoying enough without having to worry about disk arrays.

2/ snaparaid : is it concerned by the fileid problem that could lead to potential file corruption, as long as no application like onedrive or filesyncing app is not use?

Hope someone can help.

I'm getting an error where duplication is inconsistent. The file is the WPSettings.dat in the System Volume Information. Clicking duplicate now does not fix the problem. I have attached a screenshot.

I've tried searching and found similar posts but they don't have a specific resolution.

I'm running Windows 10, drivepool version 2.2.5.1237

Thanks

I have an exactly equal amount of SSD space and HDD space. All my data is on the SSDs. How do I make it so that DrivePool maintains an EXACT copy on the HDDs, but only ever reads from the SSDs?

• With the SSD Optimizer:
  • It tries to move ALL my data to the HDDs.
  • I tried checking "prioritize the placement of duplicated files on archive disks" but then it started sending my files everywhere without any real pattern to it.
• With the Drive Usage Limiter:
  • I set my SSDs to "unduplicated" and HDDs to "duplicated", but that doesn't tell me where the duplicates are going vs the originals, or where files are being read from when I'm using them. It just shows that both drives have duplicated data.

Would appreciate any and all ELI5 advice!

1. Can I specify to keep the most recent files in the SSD cache for faster reads, while also duplicating them to archive disks during the nightly schedule? Essentially files would be duplicated at night during down time, and also files wouldn't be deleted from the SSD cache. However the cache would operate on a first in/last out algorithm, so that the most recent files would be kept on the cache for faster access? once the oldest file is to be replaced by the newest file, it would just get deleted from the cache since it would have been placed on the archive disk.

2. can I specify some folders to always be on the SSD cache? for instance my Plex database would be great to have permanently in the SSD cache. I have no need to duplicate this database, as it can always be rebuilt easily.

Thanks!

i have 2x Sabrent 5 bay usb 3.2 gen 2, dock #1 filled with 5 drives, and dock #2 filled with 3 (the docks were daisy chained), + 2x samsung ssd (cache drives, connected via usb-one connected directly into the beelink, the other was connected in the 2nd usb-c slot behind a Sabrent dock);

for many months now, DrivePool has been showing several drives under 'Non-Pooled' but these drives are actually apart of the pool; i didn't have any issues with my data or DrivePool G:\, so I left it as is;

i had a very successful run of setting up WSL 2 + Docker Containers on Win11 Pro using ChatGPT! that I asked it: "some disks that are apart of the pool are showing as non-pooled, why is that?"

it returned:

TL;DR

Most likely:

✔ Drive is detected by Windows
✔ DrivePool just hasn’t reattached it
✔ Data is still safe
✔ Click Add to Pool or restart DrivePool service

Not a failure.

////

so I clicked on Add to Pool on the disks under Non-Pooled.

shortly after, one after another drives were showing as "Missing", until all 3 drives in dock #2 showed "missing";

i checked the drives in Windows Disk Management, it asked me to 'initialize' the disks, and I let it; and slowly my just-fine working DrivePool felt like it got corrupted and thus my nightmare began.

at the moment, i've completely detached dock #2; i have dock #1 and the 2x cache disks connected; I removed dock #2 disks from Drivepool; after DrivePool measuring/duplicating; DrivePool ended with "Missing Disk" saying 1of2 cache disks was missing; i was out of town and thought I detached it; i'm back with my hardware, the drive was connected the whole time; 

what should I do now? 😕

going back-I tried ChatGPT to recover the drives in dock #2; it had me try to recover the NTFS filesystem via TestDisk but that didn't seem to work so I just removed the 3x disks and am running with just dock #1 since I didn't have issues with those drives; i want to have a healthy drivepool so i can one-by-one add back dock #2 and the 3x disks; i'm confused why it now said 1of2 cache disks was missing? perhaps because i removed dock #2 and the cache disk was ext connected there, and now i removed dock #2 completely and have them connected in different ports?

It's real. Just paid a nosebleed price for a 24TB drive, and don't see many opportunities to buy more  Happened suddenly. over a time period of months. This is something new (excepting the floods).

Ideas for extending drive service life welcome. I fear we're in for a long drought unless the AI bubble bursts.

Can I rename a PoolPart.* folder?

Or when adding a hdd create a shorter name after PoolPart. ? It's too long...

Thanks!

I've already tried clicking the arrows and noticed there was absolutely no difference in speed. Is there a setting that can be enabled or something?

And another question. Is it possible to stop the current balance if i had to. I'm afraid of it losing data or stopping mid file.

I'm open to any suggestions and I wonder if this is somehow a bottle neck in windows with drivepool causing this. Manual file transfer is around 250mbps so I know it's not the controller.

TIA

And btw, there's nothing wrong with the drive, I'm just replacing it with a smaller drive to regain wasted space.  

I started reporting these bugs to StableBit ~9 months ago, and informed I would be putting this post together ~1 month ago.  Please see the disclaimer below as well, as some of this is based on observations over known facts.

You are most likely to run into these bugs with applications that: *) Synchronize or backup files, including cloud mounted drives like onedrive or dropbox *) Applications that must handle large quantities of files or monitor them for changes like coding applications (Visual Studio/ VSCode)

Still, these bugs can cause silent file corruption, file misplacement, deleted files, performance degradation, data leakage ( a file shared with someone externally could have its contents overwritten by any sensitive file on your computer), missed file changes, and potential other issues for a small portion of users (I have had nearly all these things occur).  It may also trigger some BSOD crashes, I had one such crash that is likely related.  Due to the subtle nature some of these bugs can present with, it may be hard to notice they are happening even if they are.  In addition, these issues can occur even without file mirroring and files pinned to a specific drive.  I do have some potential workarounds/suggestions at the bottom.

More details are at the bottom but the important bug facts upfront:

• Windows has a native file changed notification API using overlapped IO calls.  This allows an application to listen for changes on a folder, or a folder and sub folders, without having to constantly check every file to see if it changed.  Stablebit triggers "file changed" notifications even when files are just accessed (read) in certain ways.  Stablebit does NOT generate notification events on the parent folder when a file under it changes (Windows does).  Stablebit does NOT generate a notification event only when a FileID changes (next bug talks about FileIDs).

• Windows, like linux, has a unique ID number for each file written on the hard drive.  If there are hardlinks to the same file, it has the same unique ID (so one File ID may have multiple paths associated with it). In linux this is called the inode number, Windows calls it the FileID.  Rather than accessing a file by its path, you can open a file by its FileID.  In addition it is impossible for two files to share the same FileID, it is a 128 bit number persistent across reboots (128 bits means the number of unique numbers represented is 39 digits long, or has the uniqueness of something like the MD5 hash).  A FileID does not change when a file moves or is modified.  Stablebit, by default, supports FileIDs however they seem to be ephemeral, they do not seem to survive across reboots or file moves.  Keep in mind FileIDs are used for directories as well, it is not just files. Further, if a directory is moved/renamed not only does its FileID change but every file under it changes. I am not sure if there are other situations in which they may change.  In addition, if a descendant file/directory FileID changes due to something like a directory rename Stablebit does NOT generate a notification event that it has changed (the application gets the directory event notification but nothing on the children).

There are some other things to consider as well, DrivePool does not implement the standard windows USN Journal (a system of tracking file changes on a drive).  It specifically identifies itself as not supporting this so applications shouldn't be trying to use it with a drivepool drive. That does mean that applications that traditionally don't use the file change notification API or the FileIDs may fall back to a combination of those to accomplish what they would otherwise use the USN Journal for (and this can exacerbate the problem).  The same is true of Volume Shadow Copy (VSS) where applications that might traditionally use this cannot (and drivepool identifies it cannot do VSS) so may resort to methods below that they do not traditionally use.

Now the effects of the above bugs may not be completely apparent:

• For the overlapped IO / File change notification 

This means an application monitoring for changes on a DrivePool folder or sub-folder will get erroneous notifications files changed when anything even accesses them. Just opening something like file explorer on a folder, or even switching between applications can cause file accesses that trigger the notification. If an application takes actions on a notification and then checks the file at the end of the notification this in itself may cause another notification.  Applications that rely on getting a folder changed notification when a child changes will not get these at all with DrivePool.  If it isn't monitoring children at all just the folder, this means no notifications could be generated (vs just the child) so it could miss changes.

• For FileIDs

It depends what the application uses the FileID for but it may assume the FileID should stay the same when a file moves, as it doesn't with DrivePool this might mean it reads or backs up, or syncs the entire file again if it is moved (perf issue).  An application that uses the Windows API to open a File by its ID may not get the file it is expecting or the file that was simply moved will throw an error when opened by its old FileID as drivepool has changed the ID.   For an example lets say an application caches that the FileID for ImportantDoc1.docx is 12345 but then 12345 refers to ImportantDoc2.docx due to a restart.  If this application is a file sync application and ImportantDoc1.docx is changed remotely when it goes to write those remote changes to the local file if it uses the OpenFileById method to do so it will actually override ImportantDoc2.docx with those changes.

I didn't spend the time to read Windows file system requirements to know when Windows expects a FileID to potentially change (or not change).  It is important to note that even if theoretical changes/reuse are allowed if they are not common place (because windows uses essentially a number like an md5 hash in terms of repeats) applications may just assume it doesn't happen even if it is technically allowed to do so.  A backup of file sync program might assume that a file with specific FileID is always the same file, if FileID 12345 is c:\MyDocuments\ImportantDoc1.docx one day and then c:\MyDocuments\ImportantDoc2.docx another it may mistake document 2 for document 1, overriding important data or restore data to the wrong place.  If it is trying to create a whole drive backup it may assume it has already backed up c:\MyDocuments\ImportantDoc2.docx if it now has the same File ID as ImportantDoc1.docx by the time it reaches it (at which point DrivePool would have a different FileID for Document1).

Why might applications use FileIDs or file change notifiers? It may not seem intuitive why applications would use these but a few major reasons are: *) Performance, file change notifiers are a event/push based system so the application is told when something changes, the common alternative is a poll based system where an application must scan all the files looking for changes (and may try to rely on file timestamps or even hashing the entire file to determine this) this causes a good bit more overhead / slowdown.  *)  FileID's are nice because they already handle hardlink file de-duplication (Windows may have multiple copies of a file on a drive for various reasons, but if you backup based on FileID you backup that file once rather than multiple times.  FileIDs are also great for handling renames.  Lets say you are an application that syncs files and the user backs up c:\temp\mydir with 1000 files under it.  If they rename c:\temp\mydir to c:\temp\mydir2 an application use FileIDS can say, wait that folder is the same it was just renamed. OK rename that folder in our remote version too.  This is a very minimal operation on both ends.  With DrivePool however the FileID changes for the directory and all sub-files.  If the sync application uses this to determine changes it now uploads all these files to the system using a good bit more resources locally and remotely.  If the application also uses versioning this may be far more likely to cause a conflict with two or more clients syncing, as mass amounts of files are seemingly being changed.

Finally, even if an application is trying to monitor for FileIDs changing using the file change API, due to notification bugs above it may not get any notifications when child FileIDs change so it might assume it has not.

Real Examples
OneDrive
This started with massive onedrive failures.  I would find onedrive was re-uploading hundreds of gigabytes of images an videos multiple times a week.  These were not changing or moving.  I don't know if the issue is onedrive uses FileIDs to determine if a file is already uploaded, or if it is because when it scanned a directory it may have triggered a notification that all the files in that directory changed and based on that notification it reuploads.  After this I noticed files were becoming deleted both locally and in the cloud.  I don't know what caused this, it might have been because the old file it thought was deleted as the FileID was gone and while there was a new file (actually the same file) in its place there may have been some odd race condition.   It is also possible that it queued the file for upload, the FileID changed and when it went to open it to upload it found it was 'deleted' as the FileID no longer pointed to a file and queued the delete operation.   I also found that files that were uploaded into the cloud in one folder were sometimes downloading to an alternate folder locally.  I am guessing this is because the folder FileID changed.  It thought the 2023 folder was with ID XYZ but that now pointed to a different folder and so it put the file in the wrong place.  The final form of corruption was finding the data from one photo or video actually in a file with a completely different name.  This is almost guaranteed to be due to the FileID bugs.  This is highly destructive as backups make this far harder to correct.  With one files contents replaced with another you need to know when the good content existed and in what files were effected.  Depending on retention policies the file contents that replaced it may override the good backups before you notice.  I also had a BSOD with onedrive where it was trying to set attributes on a file and the CoveFS driver corrupted some memory.  It is possible this was a race condition as onedrive may have been doing hundreds of files very rapidly due to the bugs.  I have not captured a second BSOD due to it, but also stopped using onedrive on DrivePool due to the corruption.   Another example of this is data leakage.  Lets say you share your favorite article on kittens with a group of people.   Onedrive, believing that file has changed, goes to open it using the FileID however that file ID could essentially now correspond to any file on your computer now the contents of some sensitive file are put in the place of that kitten file, and everyone you shared it with can access it.

Visual Studio Failures
Visual studio is a code editor/compiler.  There are three distinct bugs that happen.  First, when compiling if you touched one file in a folder it seemed to recompile the entire folder, this due likely to the notification bug.  This is just a slow down, but an annoying one.  Second, Visual Studio has compiler generated code support.  This means the compiler will generate actual source code that lives next to your own source code.   Normally once compiled it doesn't regenerate and compile this source unless it must change but due to the notification bugs it regenerates this code constantly and if there is an error in other code it causes an error there causing several other invalid errors.  When debugging visual studio by default will only use symbols (debug location data) as the notifications from DrivePool happen on certain file accesses visual studio constantly thinks the source has changed since it was compiled and you will only be able to breakpoint inside source if you disable the exact symbol match default.  If you have multiple projects in a solution with one dependent on another it will often rebuild other project deps even when they haven't changed, for large solutions that can be crippling (perf issue).  Finally I often had intellisense errors showing up even though no errors during compiling, and worse intellisense would completely break at points.  All due to DrivePool.

Technical details / full background & disclaimer

I have sample code and logs to document these issues in greater detail if anyone wants to replicate it themselves.

It is important for me to state drivepool is closed source and I don't have the technical details of how it works.  I also don't have the technical details on how applications like onedrive or visual studio work.  So some of these things may be guesses as to why the applications fail/etc.

The facts stated are true (to the best of my knowledge) 

Shortly before my trial expired in October of last year I discovered some odd behavior.  I had a technical ticket filed within a week and within a month had traced down at least one of the bugs.  The issue can be seen https://stablebit.com/Admin/IssueAnalysis/28720 , it does show priority 2/important which I would assume is the second highest (probably critical or similar above).  It is great it has priority but as we are over 6 months since filed without updates I figured warning others about the potential corruption was important.  

The FileSystemWatcher API is implemented in windows using async overlapped IO the exact code can be seen: https://github.com/dotnet/runtime/blob/57bfe474518ab5b7cfe6bf7424a79ce3af9d6657/src/libraries/System.IO.FileSystem.Watcher/src/System/IO/FileSystemWatcher.Win32.cs#L32-L66

That corresponds to this kernel api:
https://learn.microsoft.com/en-us/windows/win32/fileio/synchronous-and-asynchronous-i-o

Newer api calls use GetFileInformationByHandleEx to get the FileID but with older stats calls represented by nFileIndexHigh/nFileIndexLow.  

In terms of the FileID bug I wouldn't normally have even thought about it but the advanced config (https://wiki.covecube.com/StableBit_DrivePool_2.x_Advanced_Settings) mentions this under CoveFs_OpenByFileId  "When enabled, the pool will keep track of every file ID that it gives out in pageable memory (memory that is saved to disk and loaded as necessary).".   Keeping track of files in memory is certainly very different from Windows so I thought this may be the source of issue.  I also don't know if there are caps on the maximum number of files it will track as if it resets FileIDs in situations other than reboots that could be much worse. Turning this off will atleast break nfs servers as it mentions it right in the docs "required by the NFS server".

Finally, the FileID numbers given out by DrivePool are incremental and very low.  This means when they do reset you almost certainly will get collisions with former numbers.   What is not clear is if there is the chance of potential FileID corruption issues.  If when it is assigning these ids in a multi-threaded scenario with many different files at the same time could this system fail? I have seen no proof this happens, but when incremental ids are assigned like this for mass quantities of potential files it has a higher chance of occurring.

Microsoft mentions this about deleting the USN Journal: "Deleting the change journal impacts the File Replication Service (FRS) and the Indexing Service, because it requires these services to perform a complete (and time-consuming) scan of the volume. This in turn negatively impacts FRS SYSVOL replication and replication between DFS link alternates while the volume is being rescanned.".  Now DrivePool never has the USN journal supported so it isn't exactly the same thing, but it is clear that several core Windows services do use it for normal operations I do not know what backups they use when it is unavailable. 

Potential Fixes
There are advanced settings for drivepool https://wiki.covecube.com/StableBit_DrivePool_2.x_Advanced_Settings beware these changes may break other things.
CoveFs_OpenByFileId - Set to false, by default it is true.  This will disable the OpenByFileID API.  It is clear several applications use this API.  In addition, while DrivePool may disable that function with this setting it doesn't disable FileID's themselves.  Any application using FileIDs as static identifiers for files may still run into problems. 

I would avoid any file backup/synchronization tools and DrivePool drives (if possible).  These likely have the highest chance of lost files, misplaced files, file content being mixed up, and excess resource usage.   If not avoiding consider taking file hashes for the entire drivepool directory tree.  Do this again at a later point and make sure files that shouldn't have changed still have the same hash.

If you have files that rarely change after being created then hashing each file at some point after creation and alerting if that file disappears or hash changes would easily act as an early warning to a bug here being hit.