Shane

Sure - MS is very coy about their supposed "space" out there.
And they say nothing anywhere about versioning until you hit a scenario like this.
The versions are NOT visible anywhere (easily). The only way to see what is really going on is burrow deep inside thee MS Admin Center for Sharepoint until you hit Storage Metrics and you will eventually get to a view of a single "chunk" that CloudDrive writes out to your OneDrive space:



AND then finally - click Version History to see the damage being inflicted....

The only way - you and I can clear this crap is by clicking "delete all versions" - above.
But this deletes the versions for just this single chunk.
Cloud Drive has created 500 folders - with 500 1MB chunks in each folder. (25000 chunks total).
It would take you months to visit each 1Mb chunk and click Delete All Versions.
Some files in my stash oddly have 1 version. Others have 89. Still others have 132. No rhyme no reason to any of it.
The biggest joke is in what universe could ever somehow cobble use ANY of these "older" versions and have it makes sense.
At any give time - all 25000 of these 1MB chunks (assuming the last and latest version) go together in a single unique puzzle to form the overall "data" that is backed up in our cloud drives. 
If there was ever a more useless backup option than this - I have never seen it. 
All I know is once I get this sorted by MS - I am moving to BackBlaze B2. OneDrive (Business OR personal) was never designed to be used how I want to use it (Third level offsite deep cold storage) that will most likely NEVER be used for restoration purposes ever outside of a complete global emergency that wipes house and home over here.
Finally - versioning CANNOT be turned off by you or I regardless of admin access or what not. The best I could do is REDUCE versions from an unbelievable 500 to 100 AND have the system clip any versions older than 30 days. That is simply not an option that will work for 25000 1MB chunks.
Hello Backblaze - goodbye OneDrive.
S
 

Hi!
I don't have a question, but a solution to a problem I encounted.
I encounted the following issue for a few files (10s out of a million files)
 
11:11:11.1: Warning: 0 : [FileDuplication] Error checking file for duplication consistency or duplicating file \\?\GLOBALROOT\Device\HarddiskVolumeXX\<...>. Zugriff verweigert "Zugriff verweigert" is "access denied" localized.
It took me a while to figure out what caused it. In my case there are three conditions to trigger it:
have 2 duplicated files with a different file modification time the difference in file mod time has to be greater than 60 seconds the file must be read-only (not by ACL, just the normal file system flag) To solve it I just temporarily removed the read-only flag.
My suggestion for the drivepool software:
Either improve the error message to include the real reason for the duplication error (in the UI and the log) Or ignore the read-only flag and temporarily remove it before aligning the modification dates

Thanks for the reply and for offering to investigate.
I did some more extensive troubleshooting and wanted to post the results in case it's useful.
It now appears that DrivePool itself was not the cause.
I isolated the issue by testing the exact same files in multiple ways:
Older files stored in the pool consistently read at only ~38–50 MB/s when tested over SMB using dd with iflag=direct (bypassing the Linux page cache) A hard link to the same file was just as slow, confirming it wasn't related to the DrivePool path. Creating a new physical copy of the exact same file immediately increased read speed to ~140 MB/s (SMB) A brand new file (download) read at ~135-140 MB/s as well. Finally, I used DrivePool File Placement + Balance to move one of the slow files from one physical SSD to another. After the move, the exact same file immediately increased from ~48 MB/s to ~140 MB/s. We also verified that the files were:
not fragmented (single extent), not sparse, not NTFS compressed. SMB configuration, signing, encryption and the network were also ruled out. 
The only consistent pattern is that older files are slow until they are rewritten or physically relocated, after which they become fast again.
My current theory is that this is related to SSD data retention / NAND refresh behavior rather than DrivePool itself. The system was powered off for roughly 8 months (we moved to new house and I never got the time), and rewriting the data appears to "refresh" it. Would have thought that WD RED (purchased end of 2024) shouldn't have this problem but that's the only thing I can think of. 
So I don't think there is actually a DrivePool issue here anymore.
Sorry to have wasted your time, hopefully this can help if anyone else runs inte similar symptoms.

Just a heads up, Alex did take a look into this, and did find a solution that is actually lower level, shouldn't keep the drives awake and allow them to sleep.  
You can find the installer for this version here:
https://dl.covecube.com/DrivePoolWindows/beta/download/StableBit.DrivePool_2.3.14.1744_x64_BETA.exe
 
 

Hi wecpc, that procedure will work.
It is preferable to connect all of a pool's drives at the same time (e.g. while Windows is not running or before DrivePool is installed) rather than one at a time so that DrivePool does not complain about missing drives, but DrivePool should automatically put any pool with missing disks into read-only mode until all disks are found.
If you have any custom balancing/placement settings for your pool(s) you should take note of them before migrating as you may need to redo them on the new machine, but any duplication settings will be carried across automatically.
All content should remain intact.

I would do so. Then just re-add it for Optimizer.

Hi! I would first order the priority of balancers as follows:
StableBit Scanner - if a disk goes bad you want the evacuation to take priority over anything else SSD Optimizer - when disks aren't bad you want the SSD caching to happen before anything else Disk Space Equalizer - then you want the archive disks equalized (per the manual's notes this balancer overrides anything beneath it) I also seem to recall that in some cases the Equalizer and Optimizer do not play nice together - both are "aggressive" - so of the two you might try enabling only the Equaliser first and then once the HDDs are balanced to your liking enabling the Optimizer instead (new files by default should go to whichever drive has the most available space, so if they're all the same capacity over time they should stay more or less evenly filled).

Sounds like you'd want the following for each pool?
Balancing -> Balancers -> only SSD Optimizer ticked under Drives, tick the SSD / Archive drives as appropriate to set your cache drive under Options, set sliders as desired (these only concern filling, they don't empty) under Ordered placement, leave both Unduplicated and Duplicated unticked (or, if you want to use it, make sure "Leave the files as they are" is selected). Balancing -> Settings under Automatic balancing, select Balance immediately, with the "Not more often than..." unticked under Automatic balancing - Triggers, select 100% / unticked (as you want it always moved straight away) under Plug-in settings, "Allow balancing plug-ins to force immediate balancing..." ticked (so it should move straight away anyway) under File placement settings, should be irrelevant since you're not using the File Placement section. This should result in any files copied to the pool going via your SSD cache drive first then being immediately moved to the others. As always with "production" data, I recommend confirming the behaviour is as expected with a test pool.

So I've 'fixed' this issue somewhat manually. Still not sure what's causing it.

Every time I boot up my computer, DP UI shows no disks. I have to run this in powershell:
 
$dpcmd = "C:\Program Files\StableBit\DrivePool\dpcmd.exe"
$tempLetter = "D"
$diskNumbers = @(0, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15)
foreach ($diskNum in $diskNumbers) {
    # Get the largest Basic partition with no drive letter on this disk
    $part = Get-Partition -DiskNumber $diskNum |
        Where-Object { $_.Type -eq "Basic" -and [string]$_.DriveLetter -eq "" } |
        Sort-Object Size -Descending |
        Select-Object -First 1
    if ($null -eq $part) {
        Write-Host "Disk $diskNum - No eligible partition found, skipping."
        continue
    }
    Write-Host "Disk $diskNum - Partition $($part.PartitionNumber) ($([math]::Round($part.Size / 1GB, 1)) GB) - Assigning $tempLetter`:\"
    $part | Add-PartitionAccessPath -AccessPath "$tempLetter`:\" -ErrorAction SilentlyContinue
    Start-Sleep -Seconds 2
    Write-Host "Disk $diskNum - Hinting DrivePool..."
    & $dpcmd hint-poolpart "$tempLetter`:\"
    Start-Sleep -Seconds 1
    Write-Host "Disk $diskNum - Removing $tempLetter`:\"
    $part | Remove-PartitionAccessPath -AccessPath "$tempLetter`:\" -ErrorAction SilentlyContinue
    Write-Host "Disk $diskNum - Done."
    Write-Host ""
}
Write-Host "All disks processed!"


This goes through and mounts the drive letter D:\ to the largest empty partition on each drive that is supposed to be pooled, hints drivepool of that drive, then unmounts the letter and moves on. 

I have to run this every boot in order for my pool to reappear. 

Not the worst thing in the world, but definitely annoying. It can take 20-30 minutes after running the script for the 'Measuring' step to be complete.

I fixed the problem. All is good now.
I had a permission problem. I had to reorder the permissions on each root folder. I gave them full control and the error went away. I can now see the file list under file protection also now.
 
Thanks.

UPDATE: I think I finally solved the issue.
First, I installed WD Kitfox and disabled APM on both drives through the software interface (not sure if this was contributing to the problem but i dont need or want this anyway)
Next, i noticed that write-cache was not enabled on either of the WD drives (was defaulted on "quick removal"). there is a setting to change the "write cache removal policy" in Kitfox, but it doesnt seem to work for me.
Instead i went into windows device manager, rolled out the disk drives category and double click on each affected drive > policy > "better performance" > write-cache enabled [x]
 
this did the trick, instantly all my drives are firing full speed 250+ MB/s
 
now, even tho it works and all, none of this makes any sense as to why it even works. how is it that if "drive cache enabled" was all that it took, windows explorer was still able to do full speed file transfers without it, while drivepool was not. 🤔 the world may never know
 
anyway, marking this as solved...

I ended up opening a ticket with support and provided some info they requested but to my surprise this morning, the problem seems to have solved itself. One of my systems ran a new large backup last night and the formally empty drive now has 225GB on it. I recently added 2 12TB drives to the pool so maybe the balancing algorithm just didn't see a need to use the 4TB until recently? Not sure, but it seems to be working now so I guess all's well. I'll take it.
Thanks!

Hmm. Scanner checks by disk, not by volume, so I suspect an old trick where you split the drive into multiple partitions with the bad sectors in unallocated space won't work:
Disk: |<- volume 1 -> <- unallocated space containing 8 bad sectors -> <- volume 2 ->|
Only other option I can think of is telling Scanner to NOT scan the surface of that disk automatically (in Scanner GUI, click that disk, click "Disk settings" (has the three green horizontal bars next to it), tick "Never scan surface automatically", click Save) then expand the disk's entry so you can click on Edit blocks and select "Mark all Unreadable blocks Unchecked".
Scanner should then still alert on any new SMART errors but it'll be up to you to remember to manually scan that disk from time to time.

Hi! To have your data duplicated between two sets of disks, you'll need to create two pools (one containing each set) and then add each of those pools to a third (which has duplication enabled) and put your data in the third pool. DrivePool should then read that data from the fast set but write to both sets.
Step by step:
Create a pool, we'll call it S for slow. Add your HDDs to it. Create another pool, we'll call it F for fast. Add your SSDs to it. Create a third pool, we'll call it D for data. Enable x2 duplication on it. Add the S and F pools to it. Put your data in the D pool. DrivePool should duplicate each file to one SSD and one HDD, and will try to read from the fastest (which should be the SSD). To see what drives are being accessed, you can use DrivePool's Performance section (main GUI, select the pool to observe, click on the "Performance" drop-down) or also the Windows Task Manager (Performance tab) or Windows Resource Monitor (Disk tab).
 

Lordy, Lordy.
I've spent days trying to figure out what the heck was happening with my .mkv files. For over a month.
I thought I had a bad drive (or three), even though Stablebit scanner reports no issues. Then I thought I may have network latency issues, so I went from Windows Explorer moving files across the network to using TeraCopy and performing file integrity checks. Removed the latest drives (since the problem seemed to appear after I added them). I thought that had resolved it, but then...
I *just* ripped a blu-ray, moved it to the NAS, then went to watch an episode and it froze.
I've got a lot of disks that I ripped over the last decade - to the tune of over 4000 movies (with extras) and over 600 TV shows. Yes, I still have a lot of the original media (but I've sold off a lot of it as well) -  but the HOURS of time spent ripping, sorting media files, identifying extras, chapter titles, tagging everything...  then I open a file to watch an episode and it freezes on me.
When I go back to the source file, a newly ripped .mkv reports "No valid Matroska level 1 element found" - even though I used TeraCopy to perform a hash comparison of the file when it was written to the NAS. Re-rip, recopy, same thing...  and "Read Striping" was enabled.
I can't even begin to imagine how much work I have ahead of me - first in identifying what is bad, then in restoring it. Not to mention that for some of the older stuff, I do NOT have the original media anymore. None of this is torrented - I did it all manually (I know, but it's a thing for me).
My wife was pleased that I was finally going to be boxing up the DVD/Blu-Ray collection and getting it out of the living room... I can't even begin to express my displeasure. I've been using DrivePool for years, recommending it to everyone who will listen (and cares) and now here we are.

Cheers Shane!
 
AUTOMOUNT + SCRUB (either of them or both) did the trick, now i have everything fine. Pool present and well, and no needless drive letters.
Automount + Scrub

To fix Windows no longer automatically assigning letters to external drives, try running the following command (first access the Run dialog, e.g. by using the key combination of Windows+R):
DISKPART AUTOMOUNT ENABLE I don't know if that might also help with the pool vanishing.

The attack surface of a BIOS is orders of magnitude less than a modern major OS such as macOS or Windows. Alas, my ranting on the spreading tendency of some IT institutions to treat the public as unpaid beta testers slash vulnerability finders would be off-topic. 
You could use the Contact form to request StableBit make their licensing code less dependent on the BIOS signature due to how often those get updated these days?

I deactivated my license Stopped the DrivePool service Deleted the "C:\ProgramData\StableBit DrivePool\Service\Store" folder Restarted the service: Now it's finding my missing D drive It found the previous drive pool and is re-measuring it Reactivated my license Not super satisfying, but at least it works.

Yes your pool should appear on reinstallation (Trial version).
Pretty sure you have to deactivate your license and reactivate on new install. 
Also note potential permissions issues also.
 

At one point in time I had the same configuration.  In my case the answer was YES.  When the one drive failed, I was able to remove it and my pool saw NO lose of data.  A little rebalancing was required but in the overall situation nothing was lost.  I would suggest you keep the Mirror and multiple duplication on JBODs.  A NAS can lose a little if multiple disks fail because of power bounces but if you keep a UPS online with the protections you will be fine.

Duh, that was it, thank you!

As per above "T" has to be the pool's drive letter, not the poolpart disk's drive letter.
So if your pool drive letter was instead "P" then you would use:
dpcmd ignore-poolpart P: 422717a2-17f9-4c2f-b66b-1227cf2442c0

Hi silk, my commiserations on having to deal with a borked recycle bin!
You were close. The syntax of the ignore command is: dpcmd ignore-poolpart pooldriveletterwithcolon poolpartuid
The syntax of the unignore command is: dpcmd unignore-poolpart poolpartpath
For example, in your case above (assuming T is the letter of your pool drive - not your poolpart disk), to ignore that particular poolpart you would use:
dpcmd ignore-poolpart T: 422717a2-17f9-4c2f-b66b-1227cf2442c0 While to reverse that, unignoring it, you could use:
dpcmd unignore-poolpart \\?\Volume{c29fdf21-0f4b-41b9-9a1a-c540f54e1c28}\PoolPart.422717a2-17f9-4c2f-b66b-1227cf2442c0 (as for why DrivePool put the poolpart disk back into the pool after it was removed while missing, that's because when a missing disk is removed DrivePool can't make any changes to that disk to mark that poolpart as no longer in use - and normally the expected reason to Remove a Missing disk is because the disk is dead and won't be showing back up!)

I figured it out. it was a poblem on the aws side. sorry.